Re: Some musings.

[Eric Brunner-Williams in Portland Maine <[e-mail]>]

Evening Richard,

> At a sufficient level of abstraction the PROVREG is a industry specific 
> (domain names) form of EDI. ...

Darn! I thought we were re-inventing the old xylogics terminal server
application suite -- in milking machine mode, serving a bunch of dumb
rs232 terminals on the A side, and pumping over enet on the B side to
SQL boxen. I so lack clue!

> IMHO the direction to take is to standardize the data elements ( XML 
> Schemas etc) necessary for registrars and registries to AAA and exchange 
> data but also support a number of transport mechanisms.

I suppose the operative bit here is "number of". I think we've got the
other bit covered, in principle.

I was expecting you guys to play the SCTP raga (beeponsteroids), with a
semi-respectable run into the numbers-space. Bubbles comes as a surprise.
Its so ... lightweight.  I so lack clue.

Nice to see you.

Eric

P.S. I think I actually don't know all of SOAP's shortcommings. I haven't
paid attention. Not my invited expertship brief at W3C. ENOCLUE.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8TNPkJC023265 for <[e-mail]>; Mon, 30 Sep 2002 01:25:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8TNPkXe023264 for ietf-provreg-outgoing; Mon, 30 Sep 2002 01:25:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8TNPjJC023259 for <[e-mail]>; Mon, 30 Sep 2002 01:25:45 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g8TNPPCO034120; Sun, 29 Sep 2002 19:25:25 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Richard Shockey <[e-mail]>
cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Some musings. 
In-Reply-To: Your message of "Sun, 29 Sep 2002 18:49:15 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 29 Sep 2002 19:25:25 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Evening Richard,

> At a sufficient level of abstraction the PROVREG is a industry specific 
> (domain names) form of EDI. ...

Darn! I thought we were re-inventing the old xylogics terminal server
application suite -- in milking machine mode, serving a bunch of dumb
rs232 terminals on the A side, and pumping over enet on the B side to
SQL boxen. I so lack clue!

> IMHO the direction to take is to standardize the data elements ( XML 
> Schemas etc) necessary for registrars and registries to AAA and exchange 
> data but also support a number of transport mechanisms.

I suppose the operative bit here is "number of". I think we've got the
other bit covered, in principle.

I was expecting you guys to play the SCTP raga (beeponsteroids), with a
semi-respectable run into the numbers-space. Bubbles comes as a surprise.
Its so ... lightweight.  I so lack clue.

Nice to see you.

Eric

P.S. I think I actually don't know all of SOAP's shortcommings. I haven't
paid attention. Not my invited expertship brief at W3C. ENOCLUE.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8TMnSJC023084 for <[e-mail]>; Mon, 30 Sep 2002 00:49:28 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8TMnSBQ023083 for ietf-provreg-outgoing; Mon, 30 Sep 2002 00:49:28 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8TMnRJC023078 for <[e-mail]>; Mon, 30 Sep 2002 00:49:28 +0200 (MEST)
Received: from user-uiveqeh.dsl.mindspring.com ([165.247.105.209] helo=dick.ix.netcom.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17vmsI-0006Kf-00; Sun, 29 Sep 2002 18:49:19 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 29 Sep 2002 18:49:15 -0400
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Richard Shockey <[e-mail]>
Subject: Re: Some musings.
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

>)
>
>The mapping between EPP and SMTP have to implement the missing parts 
>between EPP and the protocol itself.
>
>If we now generalize this to do "EPP over SOAP", I see a "simple" mapping 
>like the one was proposed only fulfill the requirements EPP has on 
>transport on some transport possibilities for SOAP. I.e. SOAP by itself 
>doesn't have all of the properties I list above (yes, I think that is one 
>of the _BIG_ issues with SOAP -- people have not been thinking enough, so 
>SOAP is not as well defined as people might want it to be).

SOAP's shortcomings are well know ..but the inescapable fact is its there, 
there are an increasingly number of tools available and its well supported 
by a variety of entities that use SOAP to exchange data.

At a sufficient level of abstraction the PROVREG is a industry specific 
(domain names) form of EDI. The question is then how do these entities 
...registries and registrars communicate?

EPP in and of itself if fine ..but is it the last answer in transport?  I 
dont think so.


>>I think "secure" could mean providing for the following:
>>
>>         o encrypting data (optionally)
>>         o signing data (optionally)
>>
>>Naturally, the EPP over FOO transport binding might have something useful
>>to say about formats used too.

IMHO the direction to take is to standardize the data elements ( XML 
Schemas etc) necessary for registrars and registries to AAA and exchange 
data but also support a number of transport mechanisms.

Now some of us might have preferred BEEP here..but no one wants to re fight 
that battle.



>Yes.
>
>    paf


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza   Bldg 10    Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto:[e-mail]> or <mailto:[e-mail]>
<http://shockey.us > ; <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8TGGEJC021241 for <[e-mail]>; Sun, 29 Sep 2002 18:16:14 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8TGGE9r021240 for ietf-provreg-outgoing; Sun, 29 Sep 2002 18:16:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net ([216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8TGGCJC021235 for <[e-mail]>; Sun, 29 Sep 2002 18:16:13 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g8TGFuCO032057; Sun, 29 Sep 2002 12:15:56 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Some musings. 
In-Reply-To: Your message of "Sun, 29 Sep 2002 07:05:31 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 29 Sep 2002 12:15:56 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Well, in my mind, SMTP have some properties which I feel is different 
> from TCP:
> 
>   - Messages are sent as frames, and not in a stream
>   - Messages can arrive in random order
>   - Messages can be delayed so much they can be classified as
>     lost (or even lost, but my experience is that we talk about
>     very-long-delays)

These are properties common to SMTP implemented over TCP, or UUCP, so
I'm guessing that while we started with a "like-UDP" characteristic,
we won't actually be concerned with 1122, pages 80 or 108, et. seq.

On to business.

Application-layer framing allows application-layer frame identifiers,
a feature actually awkward to extract from TCP's SND.{UNA,WND,NXT} and
SEG.ACK state variables.

Bug or feature? YMMV. RDMA over TCP is hampered by just these "strengths".
Is anyone provisioning over iSCSI or IB or ... ? Not hardly. Must everyone
use TCP? Some don't now.

Ordering of operations isn't explicit. I hadn't thought of it until now,
but I don't this minute know why a registry MUST NOT reorder or infer any
predictate command. For instance, a 2303 isn't required when a <delete>
is received by a registry, for which a <create> has yet to be received.

The idea that transport semantics are intermixed with application semantics
is one that has been proposed earlier, viz. the discussion of overloading a
bit in the TCP transport mapping to signal between two EPP endpoints.

It wouldn't be prudent of a registrar to embark upon a order-dependent
sequence of commands, and fail to ensure that the ordering information
was not evident except to the EPP state machine. The same applies for
checking the return values of the same sequence. Ironically, there are
equivalent sequences of operations which could be presented to an EPP
state machine which would have indistinguishable outcomes. The persistence
of transaction identifiers is an interesting nuance.

ops:check,create,delete,info,login,logout,poll,renew,status,transfer,update
 
Delay. We don't actually have a timeout. BigBadRegistry (BBR) could hold
ThreeLittleRegistrar's (LRR) expensive dial-up for some time, simply sending
TCP keepalives.

Still, I think this is the clearest issue -- the temporal boundaries of
GRRP and/or EPP use cases. One could claim that unlike the community of
interest at IETF-43, the community of interest at IETF-49 excluded those
use cases that were delay-tolerant, or delay-insensitive. I'm not going
to suggest otherwise -- I think I know the sweet-spots of a plurality of
the implementers in PROVREG.

Next.

> EPP need to have:
> 
>   - One open session
>   - Messages passed back and fourth between client and server
>   - An explicit close of the session
>   - Detection of sessions being broken (signaling from transport layer)
>   - Messages are not multiplied (by mistake)

I preferred the language of 06:

  EPP supports both session-less and session-oriented operating modes,

to that of 07:

  Removed description of session-less operating mode from section 2.5

If nothing else, I think my work on both active networks (see Joe Touch's
2140) and HTTP cookies has permanently weakened my notion of what the
word "session" might mean.

Passing messages appears to be covered.

An explicit close? Seems optional. YMMV.

Signaling from transport? 821 has that. Eventually ;-)

Messages not multiplied. We have idempotency, so that can't matter. We also
waived (I think) all of 1122, so this isn't about congestive collapse of
some link due to some unfortunate "optimization". This too appears to be
covered.

That seems to reduce to MUST NOT and only "session-less", with the rational
left as an exercise for the implementor clever than I.

> The mapping between EPP and SMTP have to implement the missing parts 
> between EPP and the protocol itself.

That's why I was so intrigued by Edmon Chung's note. There wasn't anything
there, which seemed slightly under-dressed.

> If we now generalize this to do "EPP over SOAP" ...

Mark Nottingham's xml-rpc suggestion at the London meeting was interesting.

Well, this is mooted in less than two days anyway.

Thanks for your note.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8TE5kJC020666 for <[e-mail]>; Sun, 29 Sep 2002 16:05:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8TE5kNe020665 for ietf-provreg-outgoing; Sun, 29 Sep 2002 16:05:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8TE5jJC020660 for <[e-mail]>; Sun, 29 Sep 2002 16:05:46 +0200 (MEST)
Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8TE4ST7027142; Sun, 29 Sep 2002 16:04:38 +0200 (MET DST)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 29 Sep 2002 16:05:33 +0200
Received: from cisco.com ([171.68.225.134]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 29 Sep 2002 16:05:33 +0200
Date: Sun, 29 Sep 2002 07:05:31 -0700
Subject: Re: Some musings.
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: "'[e-mail]'" <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-OriginalArrivalTime: 29 Sep 2002 14:05:33.0797 (UTC) FILETIME=[4709D150:01C267C1]
Sender: [e-mail]
Precedence: bulk

On Friday, September 27, 2002, at 08:50 AM, Eric Brunner-Williams in 
Portland Maine wrote:

> So, idiot that I am, I've talked (typed actually) my way into thinking
> that the issues that you could be thinking of would be solved if the 
> EPP
> over FOO transport binding (optionally) provides for the following:
>
> 	o a mechanism to provide a UID (or non-wrapped in reasonable time),
> 	o a mechanism to provide for non-repudiation of origin,
> and
> 	o a mechanism to provide for non-repudiation of receipt.
>
> I think that covers [lost,retransmission,ordering].

Well, in my mind, SMTP have some properties which I feel is different 
from TCP:

  - Messages are sent as frames, and not in a stream
  - Messages can arrive in random order
  - Messages can be delayed so much they can be classified as
    lost (or even lost, but my experience is that we talk about
    very-long-delays)

EPP need to have:

  - One open session
  - Messages passed back and fourth between client and server
  - An explicit close of the session
  - Detection of sessions being broken (signaling from transport layer)
  - Messages are not multiplied (by mistake)

The mapping between EPP and SMTP have to implement the missing parts 
between EPP and the protocol itself.

If we now generalize this to do "EPP over SOAP", I see a "simple" 
mapping like the one was proposed only fulfill the requirements EPP has 
on transport on some transport possibilities for SOAP. I.e. SOAP by 
itself doesn't have all of the properties I list above (yes, I think 
that is one of the _BIG_ issues with SOAP -- people have not been 
thinking enough, so SOAP is not as well defined as people might want it 
to be).

> I think "secure" could mean providing for the following:
>
> 	o encrypting data (optionally)
> 	o signing data (optionally)
>
> Naturally, the EPP over FOO transport binding might have something 
> useful
> to say about formats used too.

Yes.

    paf



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RFonJC006544 for <[e-mail]>; Fri, 27 Sep 2002 17:50:49 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8RFonul006543 for ietf-provreg-outgoing; Fri, 27 Sep 2002 17:50:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RFomJC006538 for <[e-mail]>; Fri, 27 Sep 2002 17:50:48 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g8RFowCO014629; Fri, 27 Sep 2002 11:50:58 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Some musings.
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 27 Sep 2002 11:50:58 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Morning-Afternoon Patrick,

Taking the "... acts like UDP ..." and "... issues with SMTP..." as our
starting points for this morning's koffee-klatch. Please pull up 1122
in your editor of choice. I assume you are wearing your AD hat.

A transport does bookkeeping and retransmission, and eventually offers
...  8-bit binary stream semantics ... fine.

But what part of this resolves the issues?

Now move down to page 108 in 1122 and mull over the requirement summary.
One or more of these is missing from, or denoted differently in, at page
80, for UDP.

How far does [lost,retransmission,ordering,etc.] of application-layer
program data chunks extend?

What does [secure] mean?

I can't read your mind.

Suppose we have SMTP over TCP. Presumably whatever our concerns are, they
are not in the solved-by-stream-semantics problem domain. Something along
the lines of end-to-end application-layer semantics, like session state.

If we have SMTP over UUCP (and why not?) 1122 falls out of the picture,
or at least its temporal guarantees within the boundaries of a socket's
connection life-time. We still get end-to-end application-layer semantics,
with store-and-forward best-effort replacing the (gatewayed best-effort) 
single socket.

So, idiot that I am, I've talked (typed actually) my way into thinking
that the issues that you could be thinking of would be solved if the EPP
over FOO transport binding (optionally) provides for the following:

	o a mechanism to provide a UID (or non-wrapped in reasonable time),
	o a mechanism to provide for non-repudiation of origin,
and
	o a mechanism to provide for non-repudiation of receipt.

I think that covers [lost,retransmission,ordering]. 

I think "secure" could mean providing for the following:

	o encrypting data (optionally)
	o signing data (optionally)

Naturally, the EPP over FOO transport binding might have something useful
to say about formats used too.

Let me know what I've missed. Back-of-the-moon kind of stuff. TiA.

Cheers,
Eric

P.S. I'm fond of 1009, 1122 and 1123. I hope you'll forgive my preference.
     I'm also fond of UUCP. 3335 is worth a moment's notice also.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8REuCJC005951 for <[e-mail]>; Fri, 27 Sep 2002 16:56:12 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8REuC36005950 for ietf-provreg-outgoing; Fri, 27 Sep 2002 16:56:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8REuBJC005945 for <[e-mail]>; Fri, 27 Sep 2002 16:56:11 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8REuA108718 for <[e-mail]>; Fri, 27 Sep 2002 14:56:10 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM9XRF5>; Fri, 27 Sep 2002 10:56:15 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC4B9@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Codes in draft-liu-epp-soap-00.txt
Date: Fri, 27 Sep 2002 10:56:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thanks, Scott! These are very good suggestions. We will deal with them in
the next revision.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Friday, September 27, 2002 10:29 AM
To: 'Liu, Hong'; '[e-mail]'
Subject: RE: Response Codes in draft-liu-epp-soap-00.txt


> Thanks for bringing that up. As noted in the draft, this 
> indeed is an open
> issue that requires further development. We would like to 
> hear from you and
> others on the list to get this issue resolved. As a starting 
> point, would
> you mind bring up one or two cases that you see most problematic (and
> suggestions, -:) )?

1) Page 14, use of the EPP 2200 response code to note a SOAP unknown session
error.

2) Page 15, use of the EPP 2200 response code to note a SOAP expired session
error.

3) Page 15 and 16, NOTE 1 and NOTE 2.

4) Page 17, NOTE about old EPP response code 2501.

As I said before, if you have to deal with SOAP session errors you need to
put something explicit into the SOAP header to note them.  Maybe an OPTIONAL
<epp-soap:error> element with error codes defined in your draft would do it.

A 2400 error code would probably be more appropriate to return for an EPP
command that can't be processed due to a transport-related error like this.
A 2200 response identifies an _EPP_ authentication error -- not a SOAP
error, and that can be confusing.

BTW, there are numerous instances of "exp-soap" used as a namespace in the
examples where I think you meant to use "epp-soap" instead:

S:    <epp-soap:session xmlns="urn:ietf:params:xml:ns:epp-soap-1.0"
S:         xmlns:epp-soap="urn:ietf:params:xml:ns:epp-soap-1.0"
S:         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:         xsi:schemaLocation="urn:ietf:params:xml:ns:epp-soap-1.0
S:         epp-soap-1.0.xsd" env:mustUnderstand="true">
S:        <exp-soap:clID>ClientX</clID>
S:        <exp-soap:sessionID>NV0x12aNX3YTAsdK</exp-soap:sessionID>
S:        <exp-soap:exDate>1970-01-01T00:00:00.0Z</exp-soap:exDate>

I think you can also get away with a single declaration for the epp-soap
namespace.  In the example above, you're both setting the default namespace
and then explicitly declaring epp-soap as a namespace.  You don't need to do
both.

You might want to try running the examples through a validating parser to
flush these sorts of errors.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RETgJC005712 for <[e-mail]>; Fri, 27 Sep 2002 16:29:42 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8RETgdd005711 for ietf-provreg-outgoing; Fri, 27 Sep 2002 16:29:42 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RETfJC005706 for <[e-mail]>; Fri, 27 Sep 2002 16:29:41 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA05003; Fri, 27 Sep 2002 10:29:35 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9W6X43>; Fri, 27 Sep 2002 10:29:34 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Response Codes in draft-liu-epp-soap-00.txt
Date: Fri, 27 Sep 2002 10:29:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Thanks for bringing that up. As noted in the draft, this 
> indeed is an open
> issue that requires further development. We would like to 
> hear from you and
> others on the list to get this issue resolved. As a starting 
> point, would
> you mind bring up one or two cases that you see most problematic (and
> suggestions, -:) )?

1) Page 14, use of the EPP 2200 response code to note a SOAP unknown session
error.

2) Page 15, use of the EPP 2200 response code to note a SOAP expired session
error.

3) Page 15 and 16, NOTE 1 and NOTE 2.

4) Page 17, NOTE about old EPP response code 2501.

As I said before, if you have to deal with SOAP session errors you need to
put something explicit into the SOAP header to note them.  Maybe an OPTIONAL
<epp-soap:error> element with error codes defined in your draft would do it.

A 2400 error code would probably be more appropriate to return for an EPP
command that can't be processed due to a transport-related error like this.
A 2200 response identifies an _EPP_ authentication error -- not a SOAP
error, and that can be confusing.

BTW, there are numerous instances of "exp-soap" used as a namespace in the
examples where I think you meant to use "epp-soap" instead:

S:    <epp-soap:session xmlns="urn:ietf:params:xml:ns:epp-soap-1.0"
S:         xmlns:epp-soap="urn:ietf:params:xml:ns:epp-soap-1.0"
S:         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S:         xsi:schemaLocation="urn:ietf:params:xml:ns:epp-soap-1.0
S:         epp-soap-1.0.xsd" env:mustUnderstand="true">
S:        <exp-soap:clID>ClientX</clID>
S:        <exp-soap:sessionID>NV0x12aNX3YTAsdK</exp-soap:sessionID>
S:        <exp-soap:exDate>1970-01-01T00:00:00.0Z</exp-soap:exDate>

I think you can also get away with a single declaration for the epp-soap
namespace.  In the example above, you're both setting the default namespace
and then explicitly declaring epp-soap as a namespace.  You don't need to do
both.

You might want to try running the examples through a validating parser to
flush these sorts of errors.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RDnxJC005233 for <[e-mail]>; Fri, 27 Sep 2002 15:49:59 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8RDnxiB005232 for ietf-provreg-outgoing; Fri, 27 Sep 2002 15:49:59 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RDnwJC005227 for <[e-mail]>; Fri, 27 Sep 2002 15:49:58 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8RDnw106861 for <[e-mail]>; Fri, 27 Sep 2002 13:49:58 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM9XQWJ>; Fri, 27 Sep 2002 09:50:03 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC4B0@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Response Codes in draft-liu-epp-soap-00.txt
Date: Fri, 27 Sep 2002 09:49:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

Thanks for bringing that up. As noted in the draft, this indeed is an open
issue that requires further development. We would like to hear from you and
others on the list to get this issue resolved. As a starting point, would
you mind bring up one or two cases that you see most problematic (and
suggestions, -:) )?

Cheers,

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Friday, September 27, 2002 7:41 AM
To: '[e-mail]'
Subject: Response Codes in draft-liu-epp-soap-00.txt


I noticed the notes and comments about EPP response codes in Hong's SOAP
draft.  As I see it, the basic problem is an attempt to use EPP response
codes to identify SOAP-related errors.  Rather than trying to overload EPP
responses to note SOAP-related processing errors, it would be a far better
idea to deal with SOAP errors in the SOAP header.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RDgCJC005152 for <[e-mail]>; Fri, 27 Sep 2002 15:42:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8RDgCZu005151 for ietf-provreg-outgoing; Fri, 27 Sep 2002 15:42:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RDg8JC005144 for <[e-mail]>; Fri, 27 Sep 2002 15:42:11 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8RDg5106656 for <[e-mail]>; Fri, 27 Sep 2002 13:42:05 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM9XQ4Z>; Fri, 27 Sep 2002 09:42:11 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC4AE@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: New I-D on EPP over SOAP
Date: Fri, 27 Sep 2002 09:42:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g8RDgBJC005147
Sender: [e-mail]
Precedence: bulk

Patrik,

Thanks for clarifying your concerns. We will investigate the Email transport
binding further and make changes to the draft as required.

--Hong

-----Original Message-----
From: Patrik Fältström [mailto:[e-mail]]
Sent: Friday, September 27, 2002 1:39 AM
To: Liu, Hong
Cc: '[e-mail]'; '[e-mail]'; '[e-mail]';
'[e-mail]'; McGarry, Tom; Wilhelm, Richard; Zhang, Ning
Subject: Re: New I-D on EPP over SOAP


On Thursday, September 26, 2002, at 05:51 PM, Liu, Hong wrote:

> The three published SOAP transport bindings that we are aware of are 
> HTTP,
> Email and BEEP. There are others supported by tools such as 
> SOAP::Lite, but
> these three are the ones we referred to in the references. Are there 
> other
> transport bindings you want us to add on? Do you foresee any problem 
> with
> any of these SOAP transport bindings, with the text quoted above?

I have issues with SMTP, as SMTP messages might be lost, and as far as 
I know the binding of SOAP on top of SMTP doesn't include 
retransmission of lost messages, ordering of messages etc.

I.e. for application layer processing, SMTP acts like UDP (if you allow 
me to make the comparison) and you need some binding which is 
"tcp-like" on top of SMTP to get the secure transport you need.

If SOAP over SMTP include that, fine. I don't know enough.

     paf

P.S. I will have the same issues with EPP over SMTP if that is created.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RBfDJC004267 for <[e-mail]>; Fri, 27 Sep 2002 13:41:13 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8RBfDC4004266 for ietf-provreg-outgoing; Fri, 27 Sep 2002 13:41:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8RBfCJC004261 for <[e-mail]>; Fri, 27 Sep 2002 13:41:12 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA02287 for <[e-mail]>; Fri, 27 Sep 2002 07:41:11 -0400 (EDT)
Received: by vsvapostalgw1.corp.bkup1 with Internet Mail Service (5.5.2653.19) id <TF9W6TM4>; Fri, 27 Sep 2002 07:41:10 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Response Codes in draft-liu-epp-soap-00.txt
Date: Fri, 27 Sep 2002 07:41:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I noticed the notes and comments about EPP response codes in Hong's SOAP
draft.  As I see it, the basic problem is an attempt to use EPP response
codes to identify SOAP-related errors.  Rather than trying to overload EPP
responses to note SOAP-related processing errors, it would be a far better
idea to deal with SOAP errors in the SOAP header.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8R5doJC001563 for <[e-mail]>; Fri, 27 Sep 2002 07:39:50 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8R5dnOn001562 for ietf-provreg-outgoing; Fri, 27 Sep 2002 07:39:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8R5dnJC001557 for <[e-mail]>; Fri, 27 Sep 2002 07:39:49 +0200 (MEST)
Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8R5cZRX020484; Fri, 27 Sep 2002 07:38:36 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 27 Sep 2002 07:38:54 +0200
Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 27 Sep 2002 07:38:54 +0200
Date: Fri, 27 Sep 2002 07:38:51 +0200
Subject: Re: New I-D on EPP over SOAP
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "McGarry, Tom" <[e-mail]>, "Wilhelm, Richard" <[e-mail]>, "Zhang, Ning" <[e-mail]>
To: "Liu, Hong" <[e-mail]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E3EC475@STNTEXCH1>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-OriginalArrivalTime: 27 Sep 2002 05:38:54.0172 (UTC) FILETIME=[2A9FA9C0:01C265E8]
Sender: [e-mail]
Precedence: bulk

On Thursday, September 26, 2002, at 05:51 PM, Liu, Hong wrote:

> The three published SOAP transport bindings that we are aware of are 
> HTTP,
> Email and BEEP. There are others supported by tools such as 
> SOAP::Lite, but
> these three are the ones we referred to in the references. Are there 
> other
> transport bindings you want us to add on? Do you foresee any problem 
> with
> any of these SOAP transport bindings, with the text quoted above?

I have issues with SMTP, as SMTP messages might be lost, and as far as 
I know the binding of SOAP on top of SMTP doesn't include 
retransmission of lost messages, ordering of messages etc.

I.e. for application layer processing, SMTP acts like UDP (if you allow 
me to make the comparison) and you need some binding which is 
"tcp-like" on top of SMTP to get the secure transport you need.

If SOAP over SMTP include that, fine. I don't know enough.

     paf

P.S. I will have the same issues with EPP over SMTP if that is created.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8QFpOJC024770 for <[e-mail]>; Thu, 26 Sep 2002 17:51:24 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8QFpOUP024769 for ietf-provreg-outgoing; Thu, 26 Sep 2002 17:51:24 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8QFpMJC024764 for <[e-mail]>; Thu, 26 Sep 2002 17:51:23 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8QFpL107446; Thu, 26 Sep 2002 15:51:22 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM9XJG6>; Thu, 26 Sep 2002 11:51:25 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC475@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "McGarry, Tom" <[e-mail]>, "Wilhelm, Richard" <[e-mail]>, "Zhang, Ning" <[e-mail]>, "Liu, Hong" <[e-mail]>
Subject: RE: New I-D on EPP over SOAP
Date: Thu, 26 Sep 2002 11:51:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id g8QFpOJC024765
Sender: [e-mail]
Precedence: bulk

Patrik,

Thanks for the comments. We will clarify the issue in the next revision. The
I-D may have already touched upon some of your concerns in the second
paragraph of Section 2.3, "Message Processing":

"Although SOAP supports a variety of messaging models and defines a message
format for various message patterns, this memo will assume that a
request/response process model MUST be followed for exchanging EPP messages
via SOAP. After an EPP client send an EPP message via SOAP, the client MUST
wait for a SOAP response from the EPP server before sending the next EPP
message via SOAP. An EPP server MUST explicitly reject concurrent EPP
messages from an EPP client after a session is successfully established."

What it means is that the EPP client and server should operate in the strict
ping-pong mode. If we re-emphasize them again in the introduction section,
will that be sufficent to address your concerns? Please advise.

The three published SOAP transport bindings that we are aware of are HTTP,
Email and BEEP. There are others supported by tools such as SOAP::Lite, but
these three are the ones we referred to in the references. Are there other
transport bindings you want us to add on? Do you foresee any problem with
any of these SOAP transport bindings, with the text quoted above?

Thanks!

--Hong

-----Original Message-----
From: Patrik Fältström [mailto:[e-mail]]
Sent: Thursday, September 26, 2002 1:26 AM
To: Liu, Hong
Cc: '[e-mail]'; '[e-mail]'; '[e-mail]';
'[e-mail]'; McGarry, Tom; Wilhelm, Richard; Zhang, Ning
Subject: Re: New I-D on EPP over SOAP


On Wednesday, September 25, 2002, at 09:52 PM, Liu, Hong wrote:

> I would like to let you know that we have submitted an I-D on EPP over 
> SOAP.
> Until it appears in the IETF I-D archives, you can access it via the
> following URL:
>
> http://epp-ver-04.sourceforge.net/IETF/draft-liu-epp-soap-00.txt

FYI: You have the following text in the introduction:

> It is designed to work on top of any transport bindings
>    defined for SOAP, taking advantage of the variety of SOAP software
>    tools and environments available for web services.

Note that some of the transport protocols today used for SOAP does 
_not_ fulfill the requirements that exists for EPP regarding congestion 
control, so you can not "just" have something running on top of SOAP. 
You also need to talk about the transport protocol SOAP is using.

    Regards, paf



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8Q5QMJC019818 for <[e-mail]>; Thu, 26 Sep 2002 07:26:22 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8Q5QMxn019817 for ietf-provreg-outgoing; Thu, 26 Sep 2002 07:26:22 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8Q5QKJC019810 for <[e-mail]>; Thu, 26 Sep 2002 07:26:20 +0200 (MEST)
Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8Q5OBCp012114; Thu, 26 Sep 2002 07:25:05 +0200 (MET DST)
Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 26 Sep 2002 07:25:54 +0200
Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 26 Sep 2002 07:25:53 +0200
Date: Thu, 26 Sep 2002 07:25:52 +0200
Subject: Re: New I-D on EPP over SOAP
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "McGarry, Tom" <[e-mail]>, "Wilhelm, Richard" <[e-mail]>, "Zhang, Ning" <[e-mail]>
To: "Liu, Hong" <[e-mail]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
In-Reply-To: <5E42C1C85C5D064A947CF92FADE6D82E3EC447@STNTEXCH1>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
X-OriginalArrivalTime: 26 Sep 2002 05:25:53.0714 (UTC) FILETIME=[2F057920:01C2651D]
Sender: [e-mail]
Precedence: bulk

On Wednesday, September 25, 2002, at 09:52 PM, Liu, Hong wrote:

> I would like to let you know that we have submitted an I-D on EPP over 
> SOAP.
> Until it appears in the IETF I-D archives, you can access it via the
> following URL:
>
> http://epp-ver-04.sourceforge.net/IETF/draft-liu-epp-soap-00.txt

FYI: You have the following text in the introduction:

> It is designed to work on top of any transport bindings
>    defined for SOAP, taking advantage of the variety of SOAP software
>    tools and environments available for web services.

Note that some of the transport protocols today used for SOAP does 
_not_ fulfill the requirements that exists for EPP regarding congestion 
control, so you can not "just" have something running on top of SOAP. 
You also need to talk about the transport protocol SOAP is using.

    Regards, paf



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8PJqbJC015678 for <[e-mail]>; Wed, 25 Sep 2002 21:52:37 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8PJqbP7015677 for ietf-provreg-outgoing; Wed, 25 Sep 2002 21:52:37 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8PJqaJC015672 for <[e-mail]>; Wed, 25 Sep 2002 21:52:36 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8PJqY106468; Wed, 25 Sep 2002 19:52:35 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <SZM9XBW1>; Wed, 25 Sep 2002 15:52:37 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC447@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "McGarry, Tom" <[e-mail]>, "Wilhelm, Richard" <[e-mail]>, "Zhang, Ning" <[e-mail]>, "Liu, Hong" <[e-mail]>
Subject: New I-D on EPP over SOAP
Date: Wed, 25 Sep 2002 15:52:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hi, all,

I would like to let you know that we have submitted an I-D on EPP over SOAP.
Until it appears in the IETF I-D archives, you can access it via the
following URL:

http://epp-ver-04.sourceforge.net/IETF/draft-liu-epp-soap-00.txt

This I-D is an individual submission to the Provreg WG, with the intent to
become a standard track WG document, pending the WG's approval as a new work
item. At its current shape, it is by no means meant to be a completely
cooked solution. Rather, it is intended to serve as a starting point for
further development on this topic within the WG.

We have been investigating EPP over SOAP internally for some time. Recent
discussions on the CRISP WG mailing list [1] seem to indicate that there is
a need to fill the void. We think that this may be a good time to publish
our study to the Provreg WG at large.

--Hong

[1]
https://lists.verisignlabs.com/pipermail/ietf-not43/2002-September/000247.ht
ml




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8JH4pJC016683 for <[e-mail]>; Thu, 19 Sep 2002 19:04:51 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8JH4o07016682 for ietf-provreg-outgoing; Thu, 19 Sep 2002 19:04:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8JH4nJC016677 for <[e-mail]>; Thu, 19 Sep 2002 19:04:49 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8JH4fRF084529; Thu, 19 Sep 2002 13:04:41 -0400 (EDT)
Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA19785; Thu, 19 Sep 2002 13:04:40 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0cb9afb01c684a@[192.149.252.231]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 19 Sep 2002 12:56:49 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: preparing for Atlanta (already?)
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 1:42PM -0400 9/3/02, Eric Brunner-Williams in Portland Maine wrote:
>to discuss what?

Well, apparently no one has answered this...so far...

We have one potential WG document, Scott's individual ID as mentioned here:
http://www.cafax.se/ietf-provreg/maillist/2002-09/msg00002.html

We also are due to have/decide on an SMTP as transport document. 
There was some recent activity on this list over this and some 
"volunteers" but there's no clear choice on editor.

As your chairs are loath to impose our will on the process, we 
haven't taken the initiative in naming someone to edit the document. 
Editing a document is a service to the community, so who ever does 
should know what they are getting into.

Before Jaap and I approach someone about being an editor, we propose 
that someone take it upon themself to write an initial draft of the 
document.  If there is more than one proposal, fine, we'll merge what 
needs merging.

I'm not barring Scott from writing, but it would be good to get 
someone else to take the initiative. Wink, wink, nudge, nudge. ;)

If no one steps forward by the end of September, perhaps the time 
will come for Jaap and I to approach someone.

Still...this leaves us with no *specific* reason to gather in Atlanta 
-- at this moment--, even though we now at least have an RFC 
published.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8HHTZJC022504 for <[e-mail]>; Tue, 17 Sep 2002 19:29:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8HHTZjQ022503 for ietf-provreg-outgoing; Tue, 17 Sep 2002 19:29:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8HHTYJC022498 for <[e-mail]>; Tue, 17 Sep 2002 19:29:35 +0200 (MEST)
Received: from [10.1.2.139] (helo=dun220) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 17rMAF-0002Uk-00 for <[e-mail]>; Tue, 17 Sep 2002 13:29:31 -0400
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
Subject: EPP client now posted
Date: Tue, 17 Sep 2002 13:29:30 -0400
Message-ID: <008d01c25e6f$c7cbacb0$8b02010a@dun220>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk

Hi all, 

Please find the following EPP client tool available for your use.
Please also be aware that we hope to upgrade the public EPP sandbox
server to 7/5 compliance in the October/November timeframe.    


http://www.sourceforge.net/projects/epptt/


EPPTT- Extensible Provisioning Protocol Testing Tool
 
Description:
 


The EPPTT is a flexible EPP-XML perl (Text::Template) driven TCP/IP
client for testing EPP compliant servers.  EPP-XML templates can easily
be added to support the many different versions of the draft protocol as
well as capture any extensions specific to a particular registry server.
With the ability to quickly modify the template files, this client can
service registry operators and users alike in testing with little to no
programming experience.  The EPPTT can be used standalone from the
command line or from the web-enabled.  Interaction with the EPP-server
can be logged and flagged with a pass or fail based on expected
responses all of which are viewable from the web-client for quick and
painless repetitive testing.
 
Features: 
 
EPP 02/00 and 06/04 support provided, expandable for other drafts and
extensions.
            Web based interface provides ease of use, and quick
validation.
            Advanced command line features provide great flexibility.
            SSL flexibility allows testing secure and non-secure
servers.
Load testing functionality ensures that each tested system can be put
under significant load.
            
Platform/Tools:
 
OS:      GNU/Linux (or cygwin)
Lang:    Perl + (CPAN based modules)
Depends: OpenSSL/libxml2/libxslt



 

Best Regards,

Michael Young



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8H7sKJC017449 for <[e-mail]>; Tue, 17 Sep 2002 09:54:20 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8H7sK8X017448 for ietf-provreg-outgoing; Tue, 17 Sep 2002 09:54:20 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8H7sJJC017443 for <[e-mail]>; Tue, 17 Sep 2002 09:54:19 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g8H7sCpZ057334 for <[e-mail]>; Tue, 17 Sep 2002 09:54:12 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g8H7sBJt057333 for [e-mail]; Tue, 17 Sep 2002 09:54:11 +0200 (CEST)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8GNxQJC014083 for <[e-mail]>; Tue, 17 Sep 2002 01:59:27 +0200 (MEST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g8GNxMD22367; Mon, 16 Sep 2002 16:59:22 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3375 on Generic Registry-Registrar Protocol Requirements
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 16 Sep 2002 16:59:22 -0700
Sender: [e-mail]
Precedence: bulk

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3375

        Title:	    Generic Registry-Registrar Protocol Requirements
        Author(s):  S. Hollenbeck
        Status:	    Informational
	Date:       September 2002
        Mailbox:    [e-mail]
        Pages:      21
        Characters: 46022
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-provreg-grrp-reqs-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3375.txt


This document describes high-level functional and interface
requirements for a client-server protocol for the registration and
management of Internet domain names in shared registries.  Specific
technical requirements detailed for protocol design are not presented
here.  Instead, this document focuses on the basic functions and
interfaces required of a protocol to support multiple registry and
registrar operational models.

This document is a product of the Provisioning Registry Protocl
Working Group. 

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

..

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

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

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

RETRIEVE: rfc
DOC-ID: rfc3375

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3375.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8CH9eo2004902 for <[e-mail]>; Thu, 12 Sep 2002 19:09:40 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8CH9dcR004901 for ietf-provreg-outgoing; Thu, 12 Sep 2002 19:09:39 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8CH9co2004896 for <[e-mail]>; Thu, 12 Sep 2002 19:09:38 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8CH9ZG08492 for <[e-mail]>; Thu, 12 Sep 2002 17:09:35 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <RZ7WBLZJ>; Thu, 12 Sep 2002 13:10:43 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC2FD@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: "status" element in <domain:info> response
Date: Thu, 12 Sep 2002 13:09:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thanks, Scott. That will do it.

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Wednesday, September 11, 2002 2:20 PM
To: 'Liu, Hong'; '[e-mail]'
Subject: RE: "status" element in <domain:info> response


> <HL>
> Thanks for the clarification. If at least one status tag 
> should exist, then
> the example on page 15 as well as the 
> domain_info_unauth_result.xml in the
> example package need to be fixed to include at least one status value.
> </HL>

Sigh, you found the spot I forgot that explains why it's OPTIONAL and zero
is possible.  Back to zero being the minimum.

> <HL>
> You are right, not all 17 values are allowed to co-exist at 
> the same time
> according to section 2.3. But I am having difficulty 
> understanding how 12 is
> derived from the complex rules in section 2.3. Could you 
> explain that to me?
> Thanks! 
> </HL>

The "pending" status values can't be set if the corresponding "prohibited"
status values are set; all of the "prohibited" values can be set at the same
time.  An object also can't be in both "ok" and any other status at the same
time.  The combination with the greatest number of members is thus:

clientDeleteProhibited
clientHold
clientRenewProhibited
clientTransferProhibited
clientUpdateProhibited
inactive
serverDeleteProhibited
serverHold
serverRenewProhibited
serverTransferProhibited
serverUpdateProhibited

That's 11.  OK, so I missed by one ;-).  I'll check the contact and host
combinations again to be sure they're right, too.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BIKHo2024869 for <[e-mail]>; Wed, 11 Sep 2002 20:20:17 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BIKH2e024868 for ietf-provreg-outgoing; Wed, 11 Sep 2002 20:20:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BIKFo2024862 for <[e-mail]>; Wed, 11 Sep 2002 20:20:16 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA01078; Wed, 11 Sep 2002 14:21:04 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4GTKK1>; Wed, 11 Sep 2002 14:20:06 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 14:20:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> <HL>
> Thanks for the clarification. If at least one status tag 
> should exist, then
> the example on page 15 as well as the 
> domain_info_unauth_result.xml in the
> example package need to be fixed to include at least one status value.
> </HL>

Sigh, you found the spot I forgot that explains why it's OPTIONAL and zero
is possible.  Back to zero being the minimum.

> <HL>
> You are right, not all 17 values are allowed to co-exist at 
> the same time
> according to section 2.3. But I am having difficulty 
> understanding how 12 is
> derived from the complex rules in section 2.3. Could you 
> explain that to me?
> Thanks! 
> </HL>

The "pending" status values can't be set if the corresponding "prohibited"
status values are set; all of the "prohibited" values can be set at the same
time.  An object also can't be in both "ok" and any other status at the same
time.  The combination with the greatest number of members is thus:

clientDeleteProhibited
clientHold
clientRenewProhibited
clientTransferProhibited
clientUpdateProhibited
inactive
serverDeleteProhibited
serverHold
serverRenewProhibited
serverTransferProhibited
serverUpdateProhibited

That's 11.  OK, so I missed by one ;-).  I'll check the contact and host
combinations again to be sure they're right, too.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BExLo2023386 for <[e-mail]>; Wed, 11 Sep 2002 16:59:21 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BExLWM023385 for ietf-provreg-outgoing; Wed, 11 Sep 2002 16:59:21 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BExJo2023380 for <[e-mail]>; Wed, 11 Sep 2002 16:59:20 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g8BExEZN072371; Wed, 11 Sep 2002 10:59:14 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, Asbjorn Steira <[e-mail]>, [e-mail], [e-mail]
Subject: Re: dcp expiry element 
In-Reply-To: Your message of "Wed, 11 Sep 2002 08:34:00 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 10:59:14 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Uhh, what action item?  It's an OPTIONAL element.

Check for substantive or editorial content. If editorial, use editorial
discretion.

It is up to you. No examples are required.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BEt0o2023338 for <[e-mail]>; Wed, 11 Sep 2002 16:55:00 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BEt0hb023337 for ietf-provreg-outgoing; Wed, 11 Sep 2002 16:55:00 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BEsxo2023332 for <[e-mail]>; Wed, 11 Sep 2002 16:54:59 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8BEsuG02767 for <[e-mail]>; Wed, 11 Sep 2002 14:54:56 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <RZ7WBCJZ>; Wed, 11 Sep 2002 10:56:04 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC2EF@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 10:54:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott, please see my comments below. 

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Wednesday, September 11, 2002 9:48 AM
To: 'Liu, Hong'; '[e-mail]'
Subject: RE: "status" element in <domain:info> response


> I have another question for clarification regarding the 
> "status" element in
> <domain:info> response for Domain -05. (Actually, similar 
> text appears in
> Domain -04).
> 
> On page 12, in describing <domain:status>, it says "One or 
> more OPTIONAL".
> But in the domain-1.0.xsd schema on page 38, the cardinality 
> of <status> in
> "infDataType" is minOccurs="0" and maxOccurs="12".
> 
> There are two issues involved:
> (1) Should the description on page 12 be changed from "One" to "Zero"?

No, because there always has to be at least one status value.  It should be
changed to remove the word "OPTIONAL".  The schema should be changed to
remove minOccurs="0".

<HL>
Thanks for the clarification. If at least one status tag should exist, then
the example on page 15 as well as the domain_info_unauth_result.xml in the
example package need to be fixed to include at least one status value.
</HL>

> (2) Should a cap be put on the number of statii returned? If 
> so, is the cap
> value "12" or "17"? When I check the "statusValueType" on 
> page 39, there are
> 17 values defined in the schema.

Re-read section 2.3.  There may be 17 values defined, but they can't all be
present at the same time.

<HL>
You are right, not all 17 values are allowed to co-exist at the same time
according to section 2.3. But I am having difficulty understanding how 12 is
derived from the complex rules in section 2.3. Could you explain that to me?
Thanks! 
</HL>

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDw1o2022892 for <[e-mail]>; Wed, 11 Sep 2002 15:58:01 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BDw1wt022891 for ietf-provreg-outgoing; Wed, 11 Sep 2002 15:58:01 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDvxo2022886 for <[e-mail]>; Wed, 11 Sep 2002 15:58:00 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8BDvvG00822 for <[e-mail]>; Wed, 11 Sep 2002 13:57:57 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <RZ7WBBYD>; Wed, 11 Sep 2002 09:59:05 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC2ED@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: email datatype definition in Contact -05
Date: Wed, 11 Sep 2002 09:57:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yes, you are right. I was referring to contact, not domain in this email. I
guess I was thinking of the second email while I was writing the first, -:)

-----Original Message-----
From: Hollenbeck, Scott [mailto:[e-mail]]
Sent: Wednesday, September 11, 2002 9:54 AM
To: 'Liu, Hong'; '[e-mail]'
Subject: RE: email datatype definition in Contact -05


> I have a question for clarification on the contact-1.0.xsd 
> regarding email
> datatype:
> 
> In "createType" for the <domain:create> command, email is 
> defined as of type
> "eppcom:minTokenType"

There is no email element in the schema for <domain:create>, but there is
one in <contact:create>.  I assume that's what you're referring to.

> In both "chgType" for the <domain:update> command and 
> "infDataType" for the
> <domain:info> response, email is defined as of type "token".

Yes, they should be consistently defined as eppcom:minTokenType, though
again these elements exist in the contact schema, not the domain schema.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDsJo2022830 for <[e-mail]>; Wed, 11 Sep 2002 15:54:19 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BDsJJ6022829 for ietf-provreg-outgoing; Wed, 11 Sep 2002 15:54:19 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDsIo2022824 for <[e-mail]>; Wed, 11 Sep 2002 15:54:19 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA13290; Wed, 11 Sep 2002 09:55:08 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4GS70X>; Wed, 11 Sep 2002 09:54:10 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: email datatype definition in Contact -05
Date: Wed, 11 Sep 2002 09:54:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I have a question for clarification on the contact-1.0.xsd 
> regarding email
> datatype:
> 
> In "createType" for the <domain:create> command, email is 
> defined as of type
> "eppcom:minTokenType"

There is no email element in the schema for <domain:create>, but there is
one in <contact:create>.  I assume that's what you're referring to.

> In both "chgType" for the <domain:update> command and 
> "infDataType" for the
> <domain:info> response, email is defined as of type "token".

Yes, they should be consistently defined as eppcom:minTokenType, though
again these elements exist in the contact schema, not the domain schema.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDmTo2022788 for <[e-mail]>; Wed, 11 Sep 2002 15:48:29 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BDmTdV022787 for ietf-provreg-outgoing; Wed, 11 Sep 2002 15:48:29 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDmSo2022781 for <[e-mail]>; Wed, 11 Sep 2002 15:48:28 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id JAA12864; Wed, 11 Sep 2002 09:49:14 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4GS7W2>; Wed, 11 Sep 2002 09:48:17 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Liu, Hong'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 09:48:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I have another question for clarification regarding the 
> "status" element in
> <domain:info> response for Domain -05. (Actually, similar 
> text appears in
> Domain -04).
> 
> On page 12, in describing <domain:status>, it says "One or 
> more OPTIONAL".
> But in the domain-1.0.xsd schema on page 38, the cardinality 
> of <status> in
> "infDataType" is minOccurs="0" and maxOccurs="12".
> 
> There are two issues involved:
> (1) Should the description on page 12 be changed from "One" to "Zero"?

No, because there always has to be at least one status value.  It should be
changed to remove the word "OPTIONAL".  The schema should be changed to
remove minOccurs="0".

> (2) Should a cap be put on the number of statii returned? If 
> so, is the cap
> value "12" or "17"? When I check the "statusValueType" on 
> page 39, there are
> 17 values defined in the schema.

Re-read section 2.3.  There may be 17 values defined, but they can't all be
present at the same time.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDQ4o2022515 for <[e-mail]>; Wed, 11 Sep 2002 15:26:04 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BDQ4lC022514 for ietf-provreg-outgoing; Wed, 11 Sep 2002 15:26:04 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mx01.gnr.com (mx01.gnr.com [193.109.220.157]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id g8BDQ3o2022509 for <[e-mail]>; Wed, 11 Sep 2002 15:26:03 +0200 (MEST)
Received: (qmail 11657 invoked by alias); 11 Sep 2002 13:26:00 -0000
Received: from unknown (HELO gnr-mailsweeper.gnr.com) (217.34.164.163) by muk-gnrmx-01 with SMTP; 11 Sep 2002 13:26:00 -0000
Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Wed, 11 Sep 2002 14:30:03 +0100
Received: from gnr.com ([192.168.1.111]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 11 Sep 2002 14:28:36 +0100
Message-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 14:27:41 +0100
From: Asbjorn Steira <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail]
Subject: Re: dcp expiry element
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Sep 2002 13:28:36.0546 (UTC) FILETIME=[2204AA20:01C25997]
Sender: [e-mail]
Precedence: bulk

Hollenbeck, Scott wrote:
>>the <greeting> example in the EPP-drafts (06/04 and 07/05) does not 
>>include the <expiry>-element of the <dcp>-element. It might be 
>>worthwhile having an <expiry>-element in the example.
> 
> That element is OPTIONAL.  It might be worthwhile to include it in an
> example, but it also might be worthwhile to leave it out to demonstrate that
> it _is_ optional.

I tend to find it useful to have all the elements present in the 
examples, and then from the draft (or schema) figure out if the 
different elements are optional or mandatory. But I agree, it makes 
sense to not have them there either. Basically just giving my $.02.


>>I just want to confirm that the following two examples are both valid 
>><dcp>-elements:
> Both are syntactically valid.  Just run 'em through a validating parser to
> confirm.

Thanks,

Asbjorn

-- 
Asbjorn Steira
The Global Name Registry, Limited



Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDK6o2022399 for <[e-mail]>; Wed, 11 Sep 2002 15:20:06 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BDK5s0022398 for ietf-provreg-outgoing; Wed, 11 Sep 2002 15:20:05 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BDK4o2022393 for <[e-mail]>; Wed, 11 Sep 2002 15:20:04 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8BDK2G32290 for <[e-mail]>; Wed, 11 Sep 2002 13:20:02 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <RZ7WBB3X>; Wed, 11 Sep 2002 09:21:10 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC2EB@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 09:19:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I have another question for clarification regarding the "status" element in
<domain:info> response for Domain -05. (Actually, similar text appears in
Domain -04).

On page 12, in describing <domain:status>, it says "One or more OPTIONAL".
But in the domain-1.0.xsd schema on page 38, the cardinality of <status> in
"infDataType" is minOccurs="0" and maxOccurs="12".

There are two issues involved:
(1) Should the description on page 12 be changed from "One" to "Zero"?
(2) Should a cap be put on the number of statii returned? If so, is the cap
value "12" or "17"? When I check the "statusValueType" on page 39, there are
17 values defined in the schema. 

Could you please make them consistent? Thanks!

--Hong


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BD4lo2022252 for <[e-mail]>; Wed, 11 Sep 2002 15:04:47 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BD4l7B022251 for ietf-provreg-outgoing; Wed, 11 Sep 2002 15:04:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BD4jo2022246 for <[e-mail]>; Wed, 11 Sep 2002 15:04:46 +0200 (MEST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g8BD4gG31970 for <[e-mail]>; Wed, 11 Sep 2002 13:04:43 GMT
Received: by STNTIMC1 with Internet Mail Service (5.5.2653.19) id <RZ7WBBLF>; Wed, 11 Sep 2002 09:05:51 -0400
Message-ID: <5E42C1C85C5D064A947CF92FADE6D82E3EC2E9@STNTEXCH1>
From: "Liu, Hong" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: email datatype definition in Contact -05
Date: Wed, 11 Sep 2002 09:04:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Scott,

I have a question for clarification on the contact-1.0.xsd regarding email
datatype:

In "createType" for the <domain:create> command, email is defined as of type
"eppcom:minTokenType"

In both "chgType" for the <domain:update> command and "infDataType" for the
<domain:info> response, email is defined as of type "token".

It seems that they also appear in Contact -04. Would that be nice to make
the datatype definition for email consistent in the schema? Thanks!

--Hong


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BCYCo2021870 for <[e-mail]>; Wed, 11 Sep 2002 14:34:12 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BCYBi5021869 for ietf-provreg-outgoing; Wed, 11 Sep 2002 14:34:11 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BCYAo2021864 for <[e-mail]>; Wed, 11 Sep 2002 14:34:10 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA08994; Wed, 11 Sep 2002 08:34:59 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4HJHYW>; Wed, 11 Sep 2002 08:34:01 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, Asbjorn Steira <[e-mail]>
Cc: [e-mail]
Subject: RE: dcp expiry element 
Date: Wed, 11 Sep 2002 08:34:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Looks good to me. Good catch too. Action item to Scott. Thanks.

Uhh, what action item?  It's an OPTIONAL element.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BCGuo2021685 for <[e-mail]>; Wed, 11 Sep 2002 14:16:56 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BCGulF021684 for ietf-provreg-outgoing; Wed, 11 Sep 2002 14:16:56 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BCGso2021679 for <[e-mail]>; Wed, 11 Sep 2002 14:16:55 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g8BCGpZN072020; Wed, 11 Sep 2002 08:16:51 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Asbjorn Steira <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: dcp expiry element 
In-Reply-To: Your message of "Wed, 11 Sep 2002 11:41:48 BST." <[e-mail]> 
Date: Wed, 11 Sep 2002 08:16:51 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Looks good to me. Good catch too. Action item to Scott. Thanks.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BCDFo2021650 for <[e-mail]>; Wed, 11 Sep 2002 14:13:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BCDFwr021649 for ietf-provreg-outgoing; Wed, 11 Sep 2002 14:13:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BCDEo2021644 for <[e-mail]>; Wed, 11 Sep 2002 14:13:14 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA08229; Wed, 11 Sep 2002 08:14:08 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4GSYK1>; Wed, 11 Sep 2002 08:13:10 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Asbjorn Steira'" <[e-mail]>, [e-mail]
Subject: RE: dcp expiry element
Date: Wed, 11 Sep 2002 08:13:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> the <greeting> example in the EPP-drafts (06/04 and 07/05) does not 
> include the <expiry>-element of the <dcp>-element. It might be 
> worthwhile having an <expiry>-element in the example.

That element is OPTIONAL.  It might be worthwhile to include it in an
example, but it also might be worthwhile to leave it out to demonstrate that
it _is_ optional.

> I just want to confirm that the following two examples are both valid 
> <dcp>-elements:
> 
>      <dcp>
>        <access><all/></access>
>        <statement>
>          <purpose><admin/><prov/></purpose>
>          <recipient><ours/><public/></recipient>
>          <retention><stated/></retention>
>        </statement>
>        <expiry>
>          <absolute>2004-01-19T22:00:00.0Z</absolute>
>        </expiry>
>      </dcp>
> 
>      <dcp>
>        <access><all/></access>
>        <statement>
>          <purpose><admin/><prov/></purpose>
>          <recipient><ours/><public/></recipient>
>          <retention><stated/></retention>
>        </statement>
>        <expiry>
>          <relative>P1Y2M3DT10H30M10S</relative>
>        </expiry>
>      </dcp>

Both are syntactically valid.  Just run 'em through a validating parser to
confirm.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BBgho2021351 for <[e-mail]>; Wed, 11 Sep 2002 13:42:43 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BBghtu021350 for ietf-provreg-outgoing; Wed, 11 Sep 2002 13:42:43 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mx01.gnr.com (mx01.gnr.com [193.109.220.157]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id g8BBggo2021344 for <[e-mail]>; Wed, 11 Sep 2002 13:42:42 +0200 (MEST)
Received: (qmail 10451 invoked by alias); 11 Sep 2002 11:42:39 -0000
Received: from unknown (HELO gnr-mailsweeper.gnr.com) (217.34.164.163) by muk-gnrmx-01 with SMTP; 11 Sep 2002 11:42:39 -0000
Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 11 Sep 2002 11:44:08 +0100
Received: from gnr.com ([192.168.1.111]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 11 Sep 2002 11:42:42 +0100
Message-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 11:41:48 +0100
From: Asbjorn Steira <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: dcp expiry element
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Sep 2002 10:42:42.0093 (UTC) FILETIME=[F4B3ADD0:01C2597F]
Sender: [e-mail]
Precedence: bulk

Hi,

the <greeting> example in the EPP-drafts (06/04 and 07/05) does not 
include the <expiry>-element of the <dcp>-element. It might be 
worthwhile having an <expiry>-element in the example.

I just want to confirm that the following two examples are both valid 
<dcp>-elements:

     <dcp>
       <access><all/></access>
       <statement>
         <purpose><admin/><prov/></purpose>
         <recipient><ours/><public/></recipient>
         <retention><stated/></retention>
       </statement>
       <expiry>
         <absolute>2004-01-19T22:00:00.0Z</absolute>
       </expiry>
     </dcp>

     <dcp>
       <access><all/></access>
       <statement>
         <purpose><admin/><prov/></purpose>
         <recipient><ours/><public/></recipient>
         <retention><stated/></retention>
       </statement>
       <expiry>
         <relative>P1Y2M3DT10H30M10S</relative>
       </expiry>
     </dcp>



-- 
Asbjorn Steira
The Global Name Registry, Limited



Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8AFpWo2013028 for <[e-mail]>; Tue, 10 Sep 2002 17:51:32 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8AFpWpI013027 for ietf-provreg-outgoing; Tue, 10 Sep 2002 17:51:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8AFpVo2013022 for <[e-mail]>; Tue, 10 Sep 2002 17:51:31 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g8AFpcZN058877; Tue, 10 Sep 2002 11:51:39 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: draft-ietf-provreg-epp-07.txt, 5. Internationalization Consid erations 
In-Reply-To: Your message of "Tue, 10 Sep 2002 11:12:28 EDT." <[e-mail]> 
Date: Tue, 10 Sep 2002 11:51:38 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Seems reasonable to me.  I'll queue this for later as Patrik has the updated
> documents, and we're waiting for feedback from the IESG review.

Yup.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8AFCYo2012577 for <[e-mail]>; Tue, 10 Sep 2002 17:12:34 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8AFCYIq012576 for ietf-provreg-outgoing; Tue, 10 Sep 2002 17:12:34 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8AFCXo2012570 for <[e-mail]>; Tue, 10 Sep 2002 17:12:33 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA18549; Tue, 10 Sep 2002 11:13:26 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4GQ72W>; Tue, 10 Sep 2002 11:12:29 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Eric Brunner-Williams in Portland Maine'" <[e-mail]>
Cc: [e-mail]
Subject: RE: draft-ietf-provreg-epp-07.txt, 5. Internationalization Consid erations
Date: Tue, 10 Sep 2002 11:12:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I got to thinking about this from issues in dnsext and aaa.
> 
> I suggest a change in the wording of para 1 of section 5.
> 
> Original:
>                         ...  EPP use with character encodings 
> other than
>   UTF-8 is NOT RECOMMENDED in environments where parser 
> encoding support
>   incompatibility might have an impact on interoperability.
> 
> Proposed Alternative:
>                             in environments where parser 
> encoding support
>   incompatibility exists, use of UTF-8 is RECOMMENDED.
> 
> Let's state the condition before the conditional, so it is 
> clearer that it
> is conditional, and actual rather than speculative.
> 
> Eric

Seems reasonable to me.  I'll queue this for later as Patrik has the updated
documents, and we're waiting for feedback from the IESG review.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8AEhAo2012208 for <[e-mail]>; Tue, 10 Sep 2002 16:43:10 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8AEhAgx012207 for ietf-provreg-outgoing; Tue, 10 Sep 2002 16:43:10 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8AEh8o2012202 for <[e-mail]>; Tue, 10 Sep 2002 16:43:09 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g8AEhGZO058603; Tue, 10 Sep 2002 10:43:17 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: draft-ietf-provreg-epp-07.txt, 5. Internationalization Considerations
Date: Tue, 10 Sep 2002 10:43:16 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Morning Scott,

I got to thinking about this from issues in dnsext and aaa.

I suggest a change in the wording of para 1 of section 5.

Original:
                        ...  EPP use with character encodings other than
  UTF-8 is NOT RECOMMENDED in environments where parser encoding support
  incompatibility might have an impact on interoperability.

Proposed Alternative:
                            in environments where parser encoding support
  incompatibility exists, use of UTF-8 is RECOMMENDED.

Let's state the condition before the conditional, so it is clearer that it
is conditional, and actual rather than speculative.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g892FDo2029540 for <[e-mail]>; Mon, 9 Sep 2002 04:15:13 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g892FD4g029539 for ietf-provreg-outgoing; Mon, 9 Sep 2002 04:15:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g892FAo2029532 for <[e-mail]>; Mon, 9 Sep 2002 04:15:11 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g892FXZN019933; Sun, 8 Sep 2002 22:15:33 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Dave Crocker <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Edmon Chung" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: epp via smtp 
In-Reply-To: Your message of "Sat, 07 Sep 2002 10:26:12 PDT." <[e-mail]> 
Date: Sun, 08 Sep 2002 22:15:33 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

[Caveat: POSIX, or rather XPG is assumed, not because it is the sole standard,
 but because it (XPG) is something I'm familiar with, and fond of. Like one
 of my kids.

 What follows assumes some set of files contain something of interest, e.g.,
 domain_create.xml, some 935 bytes of XML.
]


Dave,

Example: % mailx epp@f.q.d.n < domain_create.xml

The send-side mail spooling system performs read() of 935 bytes (from the
domain_create.xml file) and performs a write() of 936 bytes (trailing null)
to a temporary file. It proceeds to call gettimeofday() to prepend some 25
bytes of cruft before handing it off via fork()/exec() to another process,
the MTA, sendmail in this case, and unlink() the temporary file.

The receive-side mail spooling system performs similarly, with the spooled
instance of the message copied to some MUA-specific location, then unlinked.
I'll look at Vixie/Avolio and the source RSN to make sure my memory of XPG,
now POSIX, isn't a happy personal fiction.

While the <converted, or a term of your choosing> 935 bytes (plus cruft)
are managed by the two (or more) communicating MTAs, and the original is
optionally deleted at unlink()-time from the originating host (see also
the -r (remove) and the -s (symlink) options to lpr(1), similar semantics),
and not yet writen-and-sync'd into the portion of the filesystem managed
by the receiving or final MTA's spooler, one or more things may occur:

	o normal delivery (hooray!)
	o crash of either endpoint, or the relay(s) (boo!)
	o error of name to adderess resolution (hiss!)
	o network partition (ouch!)
	o sunspots and/or summer vacation (hooray!)

While unlikely, and possibly having only transient effect (that is, having
some temporal semantics such as spooled store-and-forward), these are all
quite different from, to quote my comment to Edmond, 

	[a] cron-driven sequence of shell commands shuffleing a set of
	*.xml files from a test directory to a server's i/o interface

Other than pilot-error, my cron-driven scripts lack the latency properties
and most of these potential, and frequently actual, failure conditions, of
SMTP transport sequences having some similar property of end-point delivery.

What I ment by "convert" was the temporal, and persistence, properties of
delivery of 935 bytes, from those of a file, to those of a message. I'll
pass on the serialization and on-the-wire stuff, other than those three
conditions I've mentioned.

Is it clear that if two processes are functionally indistinguishable,
but temporally distinguishable, or are non-functionally distinct, the
two processes are not identical? It is to me, but there are a lot of
folks a whole lot smarter than me, such as yourself, so I could be off
(comfortably) in a field of my own.

Have I answered your question? I seem to have deleted your last note,
which is sort of my point. Mail's permanence in the hands of a MUA is less
than that of files grazed only by open()/read() sequences of operations
by benevolent filesystems.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87Kcto2022359 for <[e-mail]>; Sat, 7 Sep 2002 22:38:55 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g87KctYE022358 for ietf-provreg-outgoing; Sat, 7 Sep 2002 22:38:55 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87Kcro2022353 for <[e-mail]>; Sat, 7 Sep 2002 22:38:54 +0200 (MEST)
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id NAA15418; Sat, 7 Sep 2002 13:50:54 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta)
Date: Sat, 07 Sep 2002 13:38:11 -0700
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: epp via smtp 
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Sat, 07 Sep 2002 10:26:12 PDT." <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 01:32 PM 9/7/2002 -0400, Eric Brunner-Williams in Portland Maine wrote:
> > the operative part of the question was the word "convert".
>
>I can't help you on matters of faith.

Then it's a good thing this was about your clarifying what you meant, 
rather than any sort of matter of faith, on the theory that you used the 
word "convert" to refer to something technical.

To refresh your memory, you said:

>What it really does is convert SMTP sessions (optionally containing EPP
>messages) to/from (optionally) EPP messages?


So the question is what you mean by "covert smtp session"?  What does it 
mean to convert an smtp session to/from an application message?

d/

----------
Dave Crocker <mailto:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87HWko2021668 for <[e-mail]>; Sat, 7 Sep 2002 19:32:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g87HWk4M021667 for ietf-provreg-outgoing; Sat, 7 Sep 2002 19:32:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87HWio2021662 for <[e-mail]>; Sat, 7 Sep 2002 19:32:44 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g87HXJg0000489; Sat, 7 Sep 2002 13:33:19 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Dave Crocker <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Edmon Chung" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: epp via smtp 
In-Reply-To: Your message of "Sat, 07 Sep 2002 10:01:10 PDT." <[e-mail]> 
Date: Sat, 07 Sep 2002 13:33:19 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> >What bits are you using?
>
> Eric, I don't understand your question.

Assume that Neteka is using some mlm other than /bin/mail, and some
mlm-to-epp mechanism other than mv, what?

As I said, and implementation question, and as he isn't using headers ...

Well, this has gone on long enough.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87HVWo2021645 for <[e-mail]>; Sat, 7 Sep 2002 19:31:32 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g87HVWME021644 for ietf-provreg-outgoing; Sat, 7 Sep 2002 19:31:32 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87HVUo2021639 for <[e-mail]>; Sat, 7 Sep 2002 19:31:31 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g87HW5g0000485; Sat, 7 Sep 2002 13:32:05 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Dave Crocker <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Edmon Chung" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: epp via smtp 
In-Reply-To: Your message of "Sat, 07 Sep 2002 10:26:12 PDT." <[e-mail]> 
Date: Sat, 07 Sep 2002 13:32:05 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> the operative part of the question was the word "convert".

I can't help you on matters of faith.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87HUMo2021634 for <[e-mail]>; Sat, 7 Sep 2002 19:30:22 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g87HUMJ0021633 for ietf-provreg-outgoing; Sat, 7 Sep 2002 19:30:22 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87HUKo2021628 for <[e-mail]>; Sat, 7 Sep 2002 19:30:21 +0200 (MEST)
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA11377; Sat, 7 Sep 2002 10:42:22 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta)
Date: Sat, 07 Sep 2002 10:26:12 -0700
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: epp via smtp 
Cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Edmon Chung" <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Sat, 07 Sep 2002 09:43:19 PDT." <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 01:05 PM 9/7/2002 -0400, Eric Brunner-Williams in Portland Maine wrote:
> > convert SMTP sessions???
>
>That set of (stateful) transactions starting with HELO (or EHLO) and ending
>with QUIT.

the operative part of the question was the word "convert".

d/


----------
Dave Crocker <mailto:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87HBGo2021538 for <[e-mail]>; Sat, 7 Sep 2002 19:11:16 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g87HBG8S021537 for ietf-provreg-outgoing; Sat, 7 Sep 2002 19:11:16 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87HBEo2021532 for <[e-mail]>; Sat, 7 Sep 2002 19:11:15 +0200 (MEST)
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA11016; Sat, 7 Sep 2002 10:23:17 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta)
Date: Sat, 07 Sep 2002 10:01:10 -0700
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: epp via smtp 
Cc: "Edmon Chung" <[e-mail]>, "Eric Brunner-Williams in Portland Maine" <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Fri, 06 Sep 2002 18:18:54 EDT." <004101c255f3$640f1880$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 09:11 PM 9/6/2002 -0400, Eric Brunner-Williams in Portland Maine wrote:
> > ... SMTP as a transport mechanism and then parse out the body portion and
> > dump it back into the regular EPP gateway ...
>Fine.

yup.

> > One SMTP message may contain multiple EPP messages.  Transaction IDs are
> > used.
>OK.

good.


> >> Content-Type
>
> > ... headers are not used as identifiers ...
>
>How about text/xml; charset=utf-8?

The set of valid content-types and valid content-transfer-encodings need to 
be defined.


> > Only PGP is used.
>
>OK.

For text on security using an application over email, probably the best 
current template is in the Fax working group documents.  For example, it 
dodges the choice between PGP and S/MIME.

>Now an implementation question or two.
>
>What bits are you using?

Eric, I don't understand your question.

>What email address(es) I can send the following

This question is essential, but the answer is not obvious.

If the service is supposed to "interact" with regular email users, then 
obviously all email addresses need to be valid.

If the service is using email simply to connect a client to a server -- and 
I think it is -- then we need the equivalent of a well-defined port 
number.  For email, that means a special mailbox string.


>What should I expect in return?

an EPP response, no?

d/

----------
Dave Crocker <mailto:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87H56o2021502 for <[e-mail]>; Sat, 7 Sep 2002 19:05:06 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g87H56wX021501 for ietf-provreg-outgoing; Sat, 7 Sep 2002 19:05:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87H54o2021496 for <[e-mail]>; Sat, 7 Sep 2002 19:05:05 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g87H5dg0000433; Sat, 7 Sep 2002 13:05:39 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Dave Crocker <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, "Edmon Chung" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: epp via smtp 
In-Reply-To: Your message of "Sat, 07 Sep 2002 09:43:19 PDT." <[e-mail]> 
Date: Sat, 07 Sep 2002 13:05:39 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> convert SMTP sessions???

That set of (stateful) transactions starting with HELO (or EHLO) and ending
with QUIT.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87GsWo2021458 for <[e-mail]>; Sat, 7 Sep 2002 18:54:32 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g87GsVeI021457 for ietf-provreg-outgoing; Sat, 7 Sep 2002 18:54:31 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87GsTo2021452 for <[e-mail]>; Sat, 7 Sep 2002 18:54:30 +0200 (MEST)
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA10545; Sat, 7 Sep 2002 10:06:26 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta)
Date: Sat, 07 Sep 2002 09:43:19 -0700
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: epp via smtp 
Cc: "Edmon Chung" <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Fri, 06 Sep 2002 21:11:52 EDT." <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 09:04 AM 9/7/2002 -0400, Eric Brunner-Williams in Portland Maine wrote:
>Edmon,
>
>Would it be accurate to say that yours is not an independent SMTP transport?

Eric, I do not understand your question.  Perhaps the easiest way to 
resolve my failure is for you to define what an "independent SMTP 
transport" for EPP would be, and how it differs from what you are calling a 
"bridge".


>What it really does is convert SMTP sessions (optionally containing EPP
>messages) to/from (optionally) EPP messages?

convert SMTP sessions???

d/

----------
Dave Crocker <mailto:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87D4Ro2020765 for <[e-mail]>; Sat, 7 Sep 2002 15:04:27 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g87D4Q0Q020764 for ietf-provreg-outgoing; Sat, 7 Sep 2002 15:04:26 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g87D4Po2020759 for <[e-mail]>; Sat, 7 Sep 2002 15:04:26 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g87D4dnn052971; Sat, 7 Sep 2002 09:04:40 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Edmon Chung" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: epp via smtp 
In-Reply-To: Your message of "Fri, 06 Sep 2002 21:11:52 EDT." <[e-mail]> 
Date: Sat, 07 Sep 2002 09:04:39 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Edmon,

Would it be accurate to say that yours is not an independent SMTP transport?

That you've implemented a "bridge", mapping (a subset of) requests/replies
to/from streams to queued files?

What it really does is convert SMTP sessions (optionally containing EPP
messages) to/from (optionally) EPP messages?

I woke up this morning asking myself how I could distinguish between one
cron-driven sequence of shell commands shuffleing a set of *.xml files from
a test directory to a server's i/o interface (file-as-a-pseudo-socket), and
an event-driven sequence of sendmail processing (shuffleing over a set of
spool files), with both employing the common server core and backend or
diagnostic stubs.

If (in my mind) I don't hang some of the semantics on 821 et seq, I end up
playing solitare with a bunch of files, with no transport dependency at all.

Well, that's this morning's coffee.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g871BYo2017536 for <[e-mail]>; Sat, 7 Sep 2002 03:11:34 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g871BX7r017535 for ietf-provreg-outgoing; Sat, 7 Sep 2002 03:11:33 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g871BWo2017530 for <[e-mail]>; Sat, 7 Sep 2002 03:11:32 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g871Bqnn004096; Fri, 6 Sep 2002 21:11:52 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Edmon Chung" <[e-mail]>
cc: "Eric Brunner-Williams in Portland Maine" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: epp via smtp 
In-Reply-To: Your message of "Fri, 06 Sep 2002 18:18:54 EDT." <004101c255f3$640f1880$[e-mail]> 
Date: Fri, 06 Sep 2002 21:11:52 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> It is honestly, fairly simple.  Reason being ease of implementation for the
> registry as well as the registrar. ...

Good.

> ... SMTP as a transport mechanism and then parse out the body portion and
> dump it back into the regular EPP gateway ...

Fine.

> One SMTP message may contain multiple EPP messages.  Transaction IDs are
> used.

OK.

>> Content-Type

> ... headers are not used as identifiers ...

How about text/xml; charset=utf-8?

>> Content-Transfer-Encoding

> 8bit

How about base64?

> None

Mime-version: 1.0

> Only PGP is used.

OK.

Now an implementation question or two.

What bits are you using?

What email address(es) I can send the following (with a useful test fqdn):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <check>
      <domain:check
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
       domain-1.0.xsd">
        <domain:name>example1.tld</domain:name>
        <domain:name>example2.tld</domain:name>
        <domain:name>example3.tld</domain:name>
      </domain:check>
    </check>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

What should I expect in return?

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g86MJJo2016770 for <[e-mail]>; Sat, 7 Sep 2002 00:19:19 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g86MJJLx016769 for ietf-provreg-outgoing; Sat, 7 Sep 2002 00:19:19 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id g86MJHo2016763 for <[e-mail]>; Sat, 7 Sep 2002 00:19:18 +0200 (MEST)
Message-ID: <004101c255f3$640f1880$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Eric Brunner-Williams in Portland Maine" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: epp via smtp 
Date: Fri, 6 Sep 2002 18:18:54 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

It is honestly, fairly simple.  Reason being ease of implementation for the
registry as well as the registrar.  Your questions indicate that a more
comprehensive approach, or perhaps I should say a more "customized" approach
designed for EPP.  We could start with a very simple definition and add to
it.  In terms of practicality, we must ask what makes the most sense to a
registry and a registrar.  In terms of an elegant solution, we could utilize
the headers and MIME much better, or even specify a new ESMTP extension to
be used.

What are the thoughts from the group in general?

Anyway, in terms of our very simple implementation, it is really just using
the SMTP as a transport mechanism and then parse out the body portion and
dump it back into the regular EPP gateway.  ie.  the XML messages are
encoded "as is" in the body of the email.  Therefore, to answer your
questions:

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[e-mail]>
> Is a single EPP message is contained within a single SMTP message?
>
> Does a single SMTP message contain only one EPP message?

One SMTP message may contain multiple EPP messages.  Transaction IDs are
used.

> What are the defined values for the Content-Type header field?

The headers are not used as identifiers within the EPP context except that
the subject identifies that it is an EPP message.

> What are the defined values for the Content-Transfer-Encoding header
field?

8bit

> What are the defined values for the Mime-Version header field?

None

> Is the mechanism defined in ESMTP used and if so, what are the one
> (or more) extensions to the SMTP service?

No.

> Is SMTP over TLS defined?
>
> Are other mechanism(s) defined for adding authentication and privacy to
> messages?

Only PGP is used.

> Are the Message-ID and In-Reply-To headers used?
>
> How are the "From:", "To:", "Cc:", etc headers used?

All headers are used as Email message headers are today.

> Are you 2821-strict or 821-tolerant w.r.t. these?
>
> Is any of the cannonical boiler-plate disturbed? IANA? Security? I18N?

When i18n is introduced, the EPP messages will contain 8bit data and use
UTF8 as the encoding.

Again, I must stress that our approach had simplicity in mind.

Edmon


> London was fun.

Europe is generally more fun than the US ;-)

> Eric
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g86LS7o2016442 for <[e-mail]>; Fri, 6 Sep 2002 23:28:07 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g86LS7cb016441 for ietf-provreg-outgoing; Fri, 6 Sep 2002 23:28:07 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g86LS6o2016436 for <[e-mail]>; Fri, 6 Sep 2002 23:28:06 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g86LSTnn003609; Fri, 6 Sep 2002 17:28:29 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Edmon Chung" <[e-mail]>
cc: [e-mail]
Subject: Re: epp via smtp 
In-Reply-To: Your message of "Fri, 06 Sep 2002 12:44:17 EDT." <095401c255c4$a5abb5c0$[e-mail]> 
Date: Fri, 06 Sep 2002 17:28:29 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Howdy Edmon,

A few questions about your development work ...

Is a single EPP message is contained within a single SMTP message?

Does a single SMTP message contain only one EPP message?

What are the defined values for the Content-Type header field?

What are the defined values for the Content-Transfer-Encoding header field?

What are the defined values for the Mime-Version header field?

Is the mechanism defined in ESMTP used and if so, what are the one
(or more) extensions to the SMTP service?

Is SMTP over TLS defined?

Are other mechanism(s) defined for adding authentication and privacy to
messages?

Are the Message-ID and In-Reply-To headers used?

How are the "From:", "To:", "Cc:", etc headers used? 

Are you 2821-strict or 821-tolerant w.r.t. these?

Is any of the cannonical boiler-plate disturbed? IANA? Security? I18N?

London was fun.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g86Gjbo2014247 for <[e-mail]>; Fri, 6 Sep 2002 18:45:37 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g86Gjbhe014246 for ietf-provreg-outgoing; Fri, 6 Sep 2002 18:45:37 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from neteka.com (www.namesbeyond.com [216.220.34.103]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id g86GjYo2014241 for <[e-mail]>; Fri, 6 Sep 2002 18:45:35 +0200 (MEST)
Message-ID: <095401c255c4$a5abb5c0$[e-mail]>
From: "Edmon Chung" <[e-mail]>
To: "Dave Crocker" <[e-mail]>, "Eric Brunner-Williams in Portland Maine" <[e-mail]>, "Edward Lewis" <[e-mail]>
Cc: "Edward Lewis" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <Your message of "Tue, 03 Sep 2002 17:45:38 EDT." <a05111b0cb99adcf42c55@[192.149.252.169]> <[e-mail]> <a05111b03b99badfdb3e0@[192.149.252.169]>
Subject: Re: epp via smtp
Date: Fri, 6 Sep 2002 12:44:17 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

So is anyone actually working on the document?
If not, I could take a crack at it since we are developing the functionality
anyway.
Edmon


----- Original Message -----
From: "Edward Lewis" <[e-mail]>
To: "Dave Crocker" <[e-mail]>; "Eric Brunner-Williams in Portland
Maine" <[e-mail]>
Cc: "Edward Lewis" <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Wednesday, September 04, 2002 8:33 AM
Subject: Re: epp via smtp


> Perhaps we have multiple volunteers...;)
>
> At 9:09 PM -0700 9/3/02, Dave Crocker wrote:
> >At 09:07 PM 9/3/2002 -0400, Eric Brunner-Williams in Portland Maine
wrote:
> >>...
> >>  > There have been some rumors of interest and even a volunteer for
this
> >>  > document ...
> >>
> >>Remind me. Who volunteered?
> >
> >'twas me.  unfortunately the task keeps getting crammed farther down
> >the stack by other priorities.
> >
> >d/
> >
> >
> >----------
> >Dave Crocker <mailto:[e-mail]>
> >TribalWise, Inc. <http://www.tribalwise.com>
> >tel [phone]; fax [phone]
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          [phone]
> ARIN Research Engineer
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g867tFo2010105 for <[e-mail]>; Fri, 6 Sep 2002 09:55:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g867tFBN010104 for ietf-provreg-outgoing; Fri, 6 Sep 2002 09:55:15 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g867tCo2010099 for <[e-mail]>; Fri, 6 Sep 2002 09:55:14 +0200 (MEST)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id g867t5oV779637; Fri, 6 Sep 2002 09:55:05 +0200 (CEST)
Received: by vespucci.nic.fr (Postfix, from userid 1000) id 0AF6610D2C; Fri,  6 Sep 2002 09:55:05 +0200 (CEST)
Date: Fri, 6 Sep 2002 09:55:04 +0200
From: Stephane Bortzmeyer <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Request to Move RFC 954 to Historic Status
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
Organization: NIC France
X-URL: http://www.nic.fr/
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Sender: [e-mail]
Precedence: bulk

[Long list of mailing lists in the Cc:, feel free to trim. I specially
believe that it is OT for Provreg.]

On Thu, Sep 05, 2002 at 01:32:26PM -0400,
 Eric Brunner-Williams in Portland Maine <[e-mail]> wrote 
 a message of 178 lines which said:

> Then there is the current ICANN announcement of some policy w.r.t. its
> Registrar Accreditation Agreement (RAA). The RAA contains language which
> appears closer to the language in 954 concerning MILNET TAC users than to
> the language in 954 concerning individual with a directory on an ARPANET or
> MILNET host. Both are in conflict with 95/46/EC, 

The RAA is certainly in conflict with 95/46/EC. That's a problem with
having the ICANN as an USAn company, not an international body: ICANN
is not supposed to take European law into consideration.

For the policy part of RFC 954 (not the protocol), I hesitate.

> I can't speculate on the actual status of :43 deployments by ccTLD operators
> located outside of North America.

According to our lawyer (IANAL), the whois of the French registry,
whois.nic.fr, is legal according to the French law (which is more
strict than 95/46/EC). Do note that we do not sale or transfer the
database in bulk. Do note also that  95/46/EC does not prevent public
directories.

> I decided not to include a mapping from the DCA language to a P3P schema,
> as for many, the policy scope question (controlling jurisdiction and legal
> theory, e.g., "fair trade" (US) vs "human rights" (EU)), not the mechanism
> for description and policy-scoped access, is more interesting, and both XML
> and schemas and/or DTDs are a distraction. I'll add it to -01.

For those interested, EUREG, following a suggestion of CORE, is
working with the W3C to develop a P3P expression of a registry's
policy. Comments on <[e-mail]>, please.
 
> If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?), 

The issue will be discussed monday at the CENTR technical meeting just
before RIPE-43.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85KfHo2005265 for <[e-mail]>; Thu, 5 Sep 2002 22:41:17 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g85KfHkg005264 for ietf-provreg-outgoing; Thu, 5 Sep 2002 22:41:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85KfDo2005259 for <[e-mail]>; Thu, 5 Sep 2002 22:41:14 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g85Kfk9X000471; Thu, 5 Sep 2002 16:41:47 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Jaap Akkerhuis <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Request to Move RFC 954 to Historic Status 
In-Reply-To: Your message of "Thu, 05 Sep 2002 22:01:09 +0200." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Sep 2002 16:41:46 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I first didn't want to react to you proposal, but since you are
> spreading this around over various maillists and have my name in there, a
> short reaction.

My appologies Jaap.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85K1Do2004906 for <[e-mail]>; Thu, 5 Sep 2002 22:01:13 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g85K1DkF004905 for ietf-provreg-outgoing; Thu, 5 Sep 2002 22:01:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85K1Co2004900 for <[e-mail]>; Thu, 5 Sep 2002 22:01:12 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g85K19pZ002717; Thu, 5 Sep 2002 22:01:09 +0200 (CEST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Request to Move RFC 954 to Historic Status 
In-reply-to: Your message of Thu, 05 Sep 2002 13:32:26 -0400. <[e-mail]> 
Date: Thu, 05 Sep 2002 22:01:09 +0200
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    
    I've cc'd the Provreg WG list due to the overlap of interest (many are also
    registrars and/or registry operators), and the W3C's P3P Spec WG list, also
    due to the overlap of interest.

I first didn't want to react to you proposal, but since you are
spreading this around over various maillists and have my name in there, a
short reaction.

Note that whois is not on the agenda of provreg.
    
    If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?),
    or ICDPPC-24 (Rigo?) this month, and ARIN-X (Ed?) next month,
    that would be a good thing.
    
If you want to have feed back from the RIPE about this, you should
get it on the agenda of the appropriate workgroups. You might even
do it by proxy, you have your ideas presented by some (nuetral)
person.

For CENTR oppinions,  suggest to contact the CENTR office. I'm not part
of that, only my organisation (SIDN) is member of CENTR.

	jaap


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85Jeko2004729 for <[e-mail]>; Thu, 5 Sep 2002 21:40:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g85Jek2m004728 for ietf-provreg-outgoing; Thu, 5 Sep 2002 21:40:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85Jejo2004723 for <[e-mail]>; Thu, 5 Sep 2002 21:40:45 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g85JeZpZ002583 for <[e-mail]>; Thu, 5 Sep 2002 21:40:35 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id g85JeZJI002582 for [e-mail]; Thu, 5 Sep 2002 21:40:35 +0200 (CEST)
Received: from narn.megacity.org (narn.megacity.org [65.242.171.25]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85ICwo2003979 for <[e-mail]>; Thu, 5 Sep 2002 20:12:59 +0200 (MEST)
Received: from Drakh.local. (fw-wp-ext.whiteplains.byramhealthcare.com [67.17.128.50] (may be forged)) (authenticated bits=0) by narn.megacity.org (8.12.6/8.12.6/Debian-2) with SMTP id g85ICNd6016758; Thu, 5 Sep 2002 14:12:24 -0400
Date: Thu, 5 Sep 2002 14:12:33 -0400
Subject: Re: Request to Move RFC 954 to Historic Status
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v543)
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: "Derek J. Balling" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.543)
Sender: [e-mail]
Precedence: bulk

On Thursday, September 5, 2002, at 01:32  PM, Eric Brunner-Williams in 
Portland Maine wrote:
> [ietf-whois and related lists]

I won't pretend that I'm on all of these mailing list in that CC line, 
but I am at least on a few. :-)

> I decided not to include a mapping from the DCA language to a P3P 
> schema,
> as for many, the policy scope question (controlling jurisdiction and 
> legal
> theory, e.g., "fair trade" (US) vs "human rights" (EU)), not the 
> mechanism
> for description and policy-scoped access, is more interesting, and 
> both XML
> and schemas and/or DTDs are a distraction. I'll add it to -01.
>
> Your comments are welcome.

A lot of this discussion appears to sort of happen "over my head" so 
please forgive me a bit if I seem stupid or something. ;-)

Part of my "night job" is the maintenance of the rfc-ignorant.org site, 
including the "whois.rfc-ignorant.org" zone, listing both individual 
domains with bad/missing/inaccurate WHOIS data, and [using a different 
result code], ccTLD's with similar problems.  We have a wide variety of 
users who utilize our service, including universities and commercial 
establishments. Some of them, obviously, use "the entire list" and some 
use "everything but the ccTLD wildcard entries". It is fairly difficult 
to ascertain accurately what percentage is behaving how, in that regard.

In our experience, there is - as you note - two different mindsets to 
registry operators. The USian perspective seems to be "you're part of a 
shared namespace, other folks have a right to know who you are", and 
the EU perspective seems to be, simply, "no you don't".  (!US,!EU) tend 
to be either split into thirds between US, EU, and "no whois server at 
all".

I believe that the main problem of RFC954 is that it tries to (well, it 
DOES) define both a protocol and a policy. In the absence of a document 
which defines "just the protocol", though, which could obsolete RFC954, 
the removal of 954 to HISTORIC status is a misnomer. It *is* an active 
protocol in use by registries around the world.

It is also an accurate statement to say that 954 is horribly out of 
date and doesn't necessarily reflect "the real state of the world" in 
many of the things it contains within the document, and I think such 
"dated" statements taint the value of both the protocol portions of the 
document, and the "spirit" of the document.

In my ideal world, I believe that the "vision" of complete WHOIS 
information that 954 describes is still, in fact, a BCP, despite what 
some EU members might think. (it's ok, you're entitled to disagree with 
me *grin*)  I can respect the desire for privacy that some feel is 
important. However, I think in a networking environment such as we have 
today, it is equally - if not more - important, to be able to contact 
folks via "a range of available methods", to be able to do so quickly 
without jumping through various registry-induced hoops, and to be able 
to obtain that complete info via a standardized protocol. (Too many 
ccTLD operators point people at web pages, which - unless there is a 
standard - breaks automated tools quite handily).

The short version of this is, I guess, "I think relegating 954 to 
HISTORIC status is premature, and should be postponed until - at bare 
minimum - a new/updated RFC defines the protocol, and preferably until 
there is both a protocol RFC as well as a policy RFC".

We can debate what the policy RFC would say at a later date. ;-)

Cheers,
D

--
+------------------------------+--------------------------------+
| Derek J. Balling             | "You can get more with a kind  |
| [e-mail]           |  word and a two-by-four, than  |
| www.megacity.org/blog/       |  you can with just a kind      |
|                              |  word."               - Marcus |
+---------------------------------------------------------------+



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85HWdo2003641 for <[e-mail]>; Thu, 5 Sep 2002 19:32:39 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g85HWdhj003640 for ietf-provreg-outgoing; Thu, 5 Sep 2002 19:32:39 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85HWbo2003635 for <[e-mail]>; Thu, 5 Sep 2002 19:32:37 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.11.6) with ESMTP id g85HWQP3075043; Thu, 5 Sep 2002 13:32:28 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Request to Move RFC 954 to Historic Status
Date: Thu, 05 Sep 2002 13:32:26 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

[ietf-whois and related lists]

I sat down with the European Commission's Call for Expressions of Interest
for the Selection of the .eu TLD Registry this week, and was pleased that
Directive 95/46/EC is the controlling framework for that registry's core
policy requirements (B.3, 1(b), Technical Annex, page 2). Here is the URL
to the EC's DP home: 

	http://europa.eu.int/comm/internal_market/en/dataprot/

That was my first imputus to finally submit an individual contribution to
move 954 from "DRAFT STANDARD" to "HISTORIC".

Now prior to Yokahama I asked around if anyone knew why and how (process)
954 had been moved from "UNKNOWN" (like 742 and 812) to "DRAFT STANDARD".
No one I asked knew, but I didn't bother to formally ask the IESG and/or
the RFC Editor. That change of status for 954 appears to have occured in
the past two years. Perhaps someone on the IESG can enlighten me.

Then there is the current ICANN announcement of some policy w.r.t. its
Registrar Accreditation Agreement (RAA). The RAA contains language which
appears closer to the language in 954 concerning MILNET TAC users than to
the language in 954 concerning individual with a directory on an ARPANET or
MILNET host. Both are in conflict with 95/46/EC, and the OEDC Guidelines
(the oecd.org link is broken, so here is Roger Clarke's restatement, itself
a useful read)

	http://www.anu.edu.au/people/Roger.Clarke/DV/PaperOECD.html

I can't speculate on the actual status of :43 deployments by ccTLD operators
located outside of North America.

I decided not to include a mapping from the DCA language to a P3P schema,
as for many, the policy scope question (controlling jurisdiction and legal
theory, e.g., "fair trade" (US) vs "human rights" (EU)), not the mechanism
for description and policy-scoped access, is more interesting, and both XML
and schemas and/or DTDs are a distraction. I'll add it to -01.

Your comments are welcome.

I've cc'd the Provreg WG list due to the overlap of interest (many are also
registrars and/or registry operators), and the W3C's P3P Spec WG list, also
due to the overlap of interest.

If anyone can provide feedback from RIPE-43 and or CENTR (Jaap?), or ICDPPC-24
(Rigo?) this month, and ARIN-X (Ed?) next month, that would be a good thing.

Please be sure to cc me if replying.

I started writing this before a comment got to me. The comment was:

> I strongly disagree with the suggestion posed by this Draft.  Whois is
> a protocol in the public domain, and people can and do still use it.
> The fact that SRI no longer supports it under DCA funding is an absurd
> argument; it is just as irrelevant as the fact that ISI no longer
> supports the DNS under DARPA funding, as it once did; should we make
> the DNS protocol Historic?
> 
> There is no protocol document obsoleting Whois, and I am not aware of
> any terrible network consequence of its operation.   People with
> security issues on their databases do not have to participate.  If
> there are technical security problems with the protocol, the IESG
> should move to develop a protocol to obsolete Whois.  In the absence of
> such a replacement, and in the absence of any demonstrable harm to the
> Internet from keeping it as a Draft Standard, moving it to Historic
> would be unnecessary and (I believe) a violatiokn of common sense
> and proper standards setting.

954 specifies not only a protocol:

	C: [::printable::]\r\n
	S: .*\r\n <socket close>

It also specifies a data colleciton practice, the DCA's for MILNET TAC users,
and for individual (users) with a directory on an ARPANET or MILNET host. The
data collection practice itself is historic. The PROPOSED STANDARD status of
a national military data collection practice is historic as well. If the IETF
has any role in non-military public registry data collection practices, by
RIRs, domain registry operators, or others choosing to use the above protocol
on port 43, 954 is historic.

Strong disagreement noted.

Eric



------- Forwarded Message

To: IETF-Announce: ;
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-brunner-rfc954-historic-00.txt
Date: Thu, 05 Sep 2002 07:18:36 -0400
Sender: [e-mail]

- --NextPart

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


	Title		: Request to Move RFC 954 to Historic Status
	Author(s)	: E. Brunner-Williams
	Filename	: draft-brunner-rfc954-historic-00.txt
	Pages		: 3
	Date		: 2002-9-4
	
This memo requests a change of the status of RFC 954,

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-brunner-rfc954-historic-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-brunner-rfc954-historic-00.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-brunner-rfc954-historic-00.txt

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

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

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85FmRo2002664 for <[e-mail]>; Thu, 5 Sep 2002 17:48:27 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g85FmRbw002663 for ietf-provreg-outgoing; Thu, 5 Sep 2002 17:48:27 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mx01.gnr.com ([193.109.220.157]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id g85FmQo2002658 for <[e-mail]>; Thu, 5 Sep 2002 17:48:26 +0200 (MEST)
Received: (qmail 30316 invoked by alias); 5 Sep 2002 15:48:22 -0000
Received: from unknown (HELO gnr-mailsweeper.gnr.com) (217.34.164.163) by muk-gnrmx-01 with SMTP; 5 Sep 2002 15:48:22 -0000
Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Thu, 5 Sep 2002 16:52:27 +0100
Received: from gnr.com ([192.168.1.111]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 5 Sep 2002 16:51:01 +0100
Message-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 16:49:53 +0100
From: Asbjorn Steira <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Edward Lewis <[e-mail]>
CC: [e-mail]
Subject: Re: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
References: <[e-mail]> <a05111b08b99ad9645684@[192.149.252.169]> <[e-mail]> <a05111b01b99d2857e553@[192.149.252.231]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Sep 2002 15:51:01.0702 (UTC) FILETIME=[08D97E60:01C254F4]
Sender: [e-mail]
Precedence: bulk

Edward Lewis wrote:
> At 4:21 PM +0100 9/5/02, Asbjorn Steira wrote:
> 
>> I think this is a WG item, but ideally I would have liked to see the 
>> guidelines as part of the base protocol.
> 
> I understand your comment, but the realities of IETF document processing 
> is that  we are better off splitting the two.  I.e., while the process 
> for the base spec has been chugging along for some time now we have been 
> learning the lessons that are (or will be) in this document.  Had we 
> waited on starting the base spec, we'd have far less experience by now.
> 
> Perhaps when we submit the documents needed to pass EPP onto the next 
> level of standard (if, when), we can roll the guidelines into the base 
> spec.

I see your point about the different levels of "maturity" of the two 
documents, and if it is at all possible at a later stage to include the 
guidelines in the base protocol (even though I can't really see that 
happening), that would be great.

Cheers,

Asbjorn

-- 
Asbjorn Steira
The Global Name Registry, Limited



Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85FVSo2002497 for <[e-mail]>; Thu, 5 Sep 2002 17:31:28 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g85FVSPB002496 for ietf-provreg-outgoing; Thu, 5 Sep 2002 17:31:28 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85FVRo2002491 for <[e-mail]>; Thu, 5 Sep 2002 17:31:27 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g856ScWQ017474; Thu, 5 Sep 2002 06:28:38 GMT
Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA19931; Thu, 5 Sep 2002 11:31:16 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b01b99d2857e553@[192.149.252.231]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <a05111b08b99ad9645684@[192.149.252.169]> <[e-mail]>
Date: Thu, 5 Sep 2002 11:31:15 -0400
To: Asbjorn Steira <[e-mail]>, Edward Lewis <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 4:21 PM +0100 9/5/02, Asbjorn Steira wrote:
>I think this is a WG item, but ideally I would have liked to see the 
>guidelines
>as part of the base protocol.

I understand your comment, but the realities of IETF document 
processing is that  we are better off splitting the two.  I.e., while 
the process for the base spec has been chugging along for some time 
now we have been learning the lessons that are (or will be) in this 
document.  Had we waited on starting the base spec, we'd have far 
less experience by now.

Perhaps when we submit the documents needed to pass EPP onto the next 
level of standard (if, when), we can roll the guidelines into the 
base spec.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85FJmo2002385 for <[e-mail]>; Thu, 5 Sep 2002 17:19:48 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g85FJmMe002384 for ietf-provreg-outgoing; Thu, 5 Sep 2002 17:19:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mx01.gnr.com ([193.109.220.157]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id g85FJlo2002379 for <[e-mail]>; Thu, 5 Sep 2002 17:19:47 +0200 (MEST)
Received: (qmail 30205 invoked by alias); 5 Sep 2002 15:19:44 -0000
Received: from unknown (HELO gnr-mailsweeper.gnr.com) (217.34.164.163) by muk-gnrmx-01 with SMTP; 5 Sep 2002 15:19:44 -0000
Received: from gnr-exch01.gnr.com (unverified) by gnr-mailsweeper.gnr.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Thu, 5 Sep 2002 16:23:45 +0100
Received: from gnr.com ([192.168.1.111]) by gnr-exch01.gnr.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 5 Sep 2002 16:22:19 +0100
Message-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 16:21:11 +0100
From: Asbjorn Steira <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Edward Lewis <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
References: <[e-mail]> <a05111b08b99ad9645684@[192.149.252.169]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Sep 2002 15:22:19.0561 (UTC) FILETIME=[065FA190:01C254F0]
Sender: [e-mail]
Precedence: bulk

I think this is a WG item, but ideally I would have liked to see the 
guidelines as part of the base protocol.

Btw, there seems to be a typo in "2.6 Command-Response Extension", where 
it refers to 2.7.1 of the base protocol. I think it should refer to 
2.7.3 instead...


Asbjorn


Edward Lewis wrote:
> Folks,
> 
> Do we make this a WG item?
> 
> At 12:54 PM -0400 8/28/02, Hollenbeck, Scott wrote:
> 
>> FYI...
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
> 
> 
>>     Title        : Guidelines for Extending the Extensible
>>                          Provisioning Protocol
>>     Author(s)    : S. Hollenbeck
>>     Filename    : draft-hollenbeck-epp-ext-00.txt
>>     Pages        : 26
>>     Date        : 2002-8-27
> 
> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-ext-00.txt
> 

-- 
Asbjorn Steira
The Global Name Registry, Limited



Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85F8Fo2002245 for <[e-mail]>; Thu, 5 Sep 2002 17:08:15 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g85F8EXl002244 for ietf-provreg-outgoing; Thu, 5 Sep 2002 17:08:14 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g85F8Do2002239 for <[e-mail]>; Thu, 5 Sep 2002 17:08:14 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8565OWQ016428; Thu, 5 Sep 2002 06:05:24 GMT
Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA15869; Thu, 5 Sep 2002 11:08:08 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b02b99d22798541@[192.136.136.60]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 5 Sep 2002 11:05:33 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: updated milestones
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

It hasn't "come out."  A "SEP 02" deadline means that I am 
optimistically hoping to see it during this month.  (I.e., SEP 02 = 
Sept 30, 2002.)

At 8:13 PM -0400 9/4/02, Eric Brunner-Williams in Portland Maine wrote:
>>  SEP 02		First draft of EPP over SMTP
>
>I missed this in -announce. When did it come out?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g850Dbo2025675 for <[e-mail]>; Thu, 5 Sep 2002 02:13:37 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g850DbvO025674 for ietf-provreg-outgoing; Thu, 5 Sep 2002 02:13:37 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g850Dao2025666 for <[e-mail]>; Thu, 5 Sep 2002 02:13:36 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.11.6) with ESMTP id g850D7P2006049; Wed, 4 Sep 2002 20:13:42 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: updated milestones 
In-Reply-To: Your message of "Wed, 04 Sep 2002 13:28:04 EDT." <a05111b05b99bf236b14e@[192.149.252.169]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 04 Sep 2002 20:13:07 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> SEP 02		First draft of EPP over SMTP

I missed this in -announce. When did it come out?



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g84HS3o2022532 for <[e-mail]>; Wed, 4 Sep 2002 19:28:03 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g84HS3Vo022531 for ietf-provreg-outgoing; Wed, 4 Sep 2002 19:28:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g84HS2o2022526 for <[e-mail]>; Wed, 4 Sep 2002 19:28:02 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g84DTe23056102; Wed, 4 Sep 2002 13:29:40 GMT
Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA03334; Wed, 4 Sep 2002 13:27:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b05b99bf236b14e@[192.149.252.169]>
Date: Wed, 4 Sep 2002 13:28:04 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: updated milestones
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

FYI -

The milestones have been updated for the group...you won't see this 
on the IETF web site until the pages are regenerated (real soon now).

Done		Decision on need for a EPP Guidelines draft
SEP 02		First draft of EPP over SMTP
SEP 02          First draft of EPP Extensions Guidelines draft
NOV 02		Schedule interoperabilty test

I'm betting[0] that Scott's Guidelines draft will be adopted by the 
WG soon, although no one else has answered my question on that...

[0] = Betting means that I think this will happen, but it's not a 
certainty.  Keeping in mind that the chairs will act according to the 
consensus of the group.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g84Cmpo2018966 for <[e-mail]>; Wed, 4 Sep 2002 14:48:51 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g84CmpfP018965 for ietf-provreg-outgoing; Wed, 4 Sep 2002 14:48:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g84Cmmo2018960 for <[e-mail]>; Wed, 4 Sep 2002 14:48:49 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g848oR23046447; Wed, 4 Sep 2002 08:50:27 GMT
Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA18042; Wed, 4 Sep 2002 08:48:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b03b99badfdb3e0@[192.149.252.169]>
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 03 Sep 2002 17:45:38 EDT." <a05111b0cb99adcf42c55@[192.149.252.169]> <[e-mail]>
Date: Wed, 4 Sep 2002 08:33:36 -0400
To: Dave Crocker <[e-mail]>, Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: epp via smtp
Cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Perhaps we have multiple volunteers...;)

At 9:09 PM -0700 9/3/02, Dave Crocker wrote:
>At 09:07 PM 9/3/2002 -0400, Eric Brunner-Williams in Portland Maine wrote:
>>...
>>  > There have been some rumors of interest and even a volunteer for this
>>  > document ...
>>
>>Remind me. Who volunteered?
>
>'twas me.  unfortunately the task keeps getting crammed farther down 
>the stack by other priorities.
>
>d/
>
>
>----------
>Dave Crocker <mailto:[e-mail]>
>TribalWise, Inc. <http://www.tribalwise.com>
>tel [phone]; fax [phone]

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g84Cmlo2018958 for <[e-mail]>; Wed, 4 Sep 2002 14:48:47 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g84CmlF0018957 for ietf-provreg-outgoing; Wed, 4 Sep 2002 14:48:47 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g84Cmko2018952 for <[e-mail]>; Wed, 4 Sep 2002 14:48:46 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g848oN23046441; Wed, 4 Sep 2002 08:50:23 GMT
Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA18036; Wed, 4 Sep 2002 08:48:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b01b99bad298235@[192.149.252.169]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 4 Sep 2002 08:29:41 -0400
To: Eric Brunner-Williams in Portland Maine <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: epp via smtp
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Jordyn... http://www.cafax.se/ietf-provreg/maillist/2002-05/msg00011.html

At 9:07 PM -0400 9/3/02, Eric Brunner-Williams in Portland Maine wrote:
>...
>>  There have been some rumors of interest and even a volunteer for this
>>  document ...
>
>Remind me. Who volunteered?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g844BCo2015538 for <[e-mail]>; Wed, 4 Sep 2002 06:11:12 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g844BCfn015537 for ietf-provreg-outgoing; Wed, 4 Sep 2002 06:11:12 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g844B8o2015532 for <[e-mail]>; Wed, 4 Sep 2002 06:11:09 +0200 (MEST)
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id VAA29013; Tue, 3 Sep 2002 21:22:40 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta)
Date: Tue, 03 Sep 2002 21:09:41 -0700
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Dave Crocker <[e-mail]>
Subject: Re: epp via smtp 
Cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Tue, 03 Sep 2002 17:45:38 EDT." <a05111b0cb99adcf42c55@[192.149.252.169]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 09:07 PM 9/3/2002 -0400, Eric Brunner-Williams in Portland Maine wrote:
>...
> > There have been some rumors of interest and even a volunteer for this
> > document ...
>
>Remind me. Who volunteered?

'twas me.  unfortunately the task keeps getting crammed farther down the 
stack by other priorities.

d/


----------
Dave Crocker <mailto:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [phone]



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8417No2013861 for <[e-mail]>; Wed, 4 Sep 2002 03:07:23 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g8417Nr2013860 for ietf-provreg-outgoing; Wed, 4 Sep 2002 03:07:23 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8417Mo2013855 for <[e-mail]>; Wed, 4 Sep 2002 03:07:22 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.11.6) with ESMTP id g8417eP2002418; Tue, 3 Sep 2002 21:07:40 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: epp via smtp 
In-Reply-To: Your message of "Tue, 03 Sep 2002 17:45:38 EDT." <a05111b0cb99adcf42c55@[192.149.252.169]> 
Date: Tue, 03 Sep 2002 21:07:40 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

...
> There have been some rumors of interest and even a volunteer for this 
> document ...

Remind me. Who volunteered?


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g840rdo2013791 for <[e-mail]>; Wed, 4 Sep 2002 02:53:39 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g840rdKU013790 for ietf-provreg-outgoing; Wed, 4 Sep 2002 02:53:39 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g840rZo2013785 for <[e-mail]>; Wed, 4 Sep 2002 02:53:36 +0200 (MEST)
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id UAA05346; Tue, 3 Sep 2002 20:54:22 -0400 (EDT)
Received: by vsvapostalgw2.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4HDB73>; Tue, 3 Sep 2002 20:53:27 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: epp via smtp
Date: Tue, 3 Sep 2002 20:53:24 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> While I'm at it...
> 
> We are behind on the current milestone:
> JUL 02       First draft of EPP over SMTP
> 
> There have been some rumors of interest and even a volunteer for this 
> document, but we've seen nothing.  Unless someone takes an active 
> step towards producing this document in the next week or two, Jaap 
> and I will ask our AD to let us drop the milestone from the 
> charter...(right, Jaap? ;) )

While I'd much prefer that someone else write the document to get some
author/editor diversity into our document pool, I'll volunteer to write such
a document iff there is some serious expression of interest from multiple
folks who wish to use such a transport.  I'll even offer to help someone
else if they want to do the bulk of the writing.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83Ljbo2012598 for <[e-mail]>; Tue, 3 Sep 2002 23:45:37 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g83Ljam3012597 for ietf-provreg-outgoing; Tue, 3 Sep 2002 23:45:36 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83LjZo2012592 for <[e-mail]>; Tue, 3 Sep 2002 23:45:36 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g83HlB23035550; Tue, 3 Sep 2002 17:47:11 GMT
Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA13015; Tue, 3 Sep 2002 17:45:32 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0cb99adcf42c55@[192.149.252.169]>
Date: Tue, 3 Sep 2002 17:45:38 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: epp via smtp
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

While I'm at it...

We are behind on the current milestone:
JUL 02       First draft of EPP over SMTP

There have been some rumors of interest and even a volunteer for this 
document, but we've seen nothing.  Unless someone takes an active 
step towards producing this document in the next week or two, Jaap 
and I will ask our AD to let us drop the milestone from the 
charter...(right, Jaap? ;) )

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83Ldpo2012534 for <[e-mail]>; Tue, 3 Sep 2002 23:39:51 +0200 (MEST)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id g83LdpPa012533 for ietf-provreg-outgoing; Tue, 3 Sep 2002 23:39:51 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83Ldno2012528 for <[e-mail]>; Tue, 3 Sep 2002 23:39:50 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g83HfO23035455; Tue, 3 Sep 2002 17:41:25 GMT
Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA12341; Tue, 3 Sep 2002 17:39:46 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0bb99adb17bcab@[192.149.252.169]>
Date: Tue, 3 Sep 2002 17:39:51 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: please remove a document from our charter
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

 From provreg: draft-ietf-provreg-epp-beep-02.txt.  This document is 
not being actively developed or improved by the WG.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83LS3o2012478 for <[e-mail]>; Tue, 3 Sep 2002 23:28:03 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g83LS37U012477 for ietf-provreg-outgoing; Tue, 3 Sep 2002 23:28:03 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83LS2o2012472 for <[e-mail]>; Tue, 3 Sep 2002 23:28:02 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g83HTa23035122; Tue, 3 Sep 2002 17:29:36 GMT
Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA10789; Tue, 3 Sep 2002 17:27:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b08b99ad9645684@[192.149.252.169]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 3 Sep 2002 17:28:00 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Re: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Folks,

Do we make this a WG item?

At 12:54 PM -0400 8/28/02, Hollenbeck, Scott wrote:
>FYI...

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]

>	Title		: Guidelines for Extending the Extensible
>                          Provisioning Protocol
>	Author(s)	: S. Hollenbeck
>	Filename	: draft-hollenbeck-epp-ext-00.txt
>	Pages		: 26
>	Date		: 2002-8-27

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

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83Hfso2010519 for <[e-mail]>; Tue, 3 Sep 2002 19:41:54 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g83Hfs99010518 for ietf-provreg-outgoing; Tue, 3 Sep 2002 19:41:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83Hfro2010513 for <[e-mail]>; Tue, 3 Sep 2002 19:41:53 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.11.6) with ESMTP id g83HgHP2000996; Tue, 3 Sep 2002 13:42:17 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: preparing for Atlanta (already?) 
In-Reply-To: Your message of "Tue, 03 Sep 2002 11:55:21 EDT." <a05111b04b99a8ae4f074@[192.149.252.169]> 
Date: Tue, 03 Sep 2002 13:42:17 -0400
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

to discuss what?


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83FtRo2009746 for <[e-mail]>; Tue, 3 Sep 2002 17:55:27 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g83FtR1t009745 for ietf-provreg-outgoing; Tue, 3 Sep 2002 17:55:27 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g83FtPo2009740 for <[e-mail]>; Tue, 3 Sep 2002 17:55:26 +0200 (MEST)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g83Buv23023872; Tue, 3 Sep 2002 11:56:58 GMT
Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA19734; Tue, 3 Sep 2002 11:55:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b04b99a8ae4f074@[192.149.252.169]>
Date: Tue, 3 Sep 2002 11:55:21 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: preparing for Atlanta (already?)
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

The call for meeting slot requests has been sent to WG chairs. 
(Already - summer is barely over!)  We did not meet in Yokohama, that 
was the first time we skipped a meeting.

List traffic has been up and discussions have been happening.  It 
seems to me that we should plan to meet in Atlanta (during November), 
probably a 2 hour slot.  Let me know if there is disagreement on this.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer