Subject: Some musings.

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 27 Sep 2002 11:50:58 -0400

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.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 29 Sep 2002 07:05:31 -0700

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

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

> to say about formats used too.

Yes.

    paf

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 29 Sep 2002 12:15:56 -0400

>     lost (or even lost, but my experience is that we talk about

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.

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

> 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

---

From: Richard Shockey <[email-masked]>
Date: Sun, 29 Sep 2002 18:49:15 -0400

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

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

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: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
<http://shockey.us > ; <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 29 Sep 2002 19:25:25 -0400

Evening Richard,

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

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

To: Richard Shockey <[email-masked]>
cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Some musings. 
Date: Sun, 29 Sep 2002 19:25:25 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Evening Richard,

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

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

Date: Sun, 29 Sep 2002 18:49:15 -0400
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: Some musings.
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Some musings. 
Date: Sun, 29 Sep 2002 12:15:56 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

On to business.

 

Next.

to that of 07:

Thanks for your note.

Eric

Date: Sun, 29 Sep 2002 07:05:31 -0700
Subject: Re: Some musings.
Cc: "[email-masked]'" <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Sender: [email-masked]

EPP need to have:

  - One open session

Yes.

    paf

To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Some musings.
Date: Fri, 27 Sep 2002 11:50:58 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

What does [secure] mean?

I can't read your mind.

Cheers,
Eric

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Codes in draft-liu-epp-soap-00.txt
Date: Fri, 27 Sep 2002 10:56:09 -0400
Sender: [email-masked]

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

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Friday, September 27, 2002 10:29 AM
To: 'Liu, Hong'; [email-masked]'
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-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Response Codes in draft-liu-epp-soap-00.txt
Date: Fri, 27 Sep 2002 10:29:25 -0400
Sender: [email-masked]

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

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Response Codes in draft-liu-epp-soap-00.txt
Date: Fri, 27 Sep 2002 09:49:57 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Friday, September 27, 2002 7:41 AM
To: [email-masked]'
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-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: New I-D on EPP over SOAP
Date: Fri, 27 Sep 2002 09:42:06 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Friday, September 27, 2002 1:39 AM
To: Liu, Hong
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; 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.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Response Codes in draft-liu-epp-soap-00.txt
Date: Fri, 27 Sep 2002 07:41:08 -0400
Sender: [email-masked]

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-

Date: Fri, 27 Sep 2002 07:38:51 +0200
Subject: Re: New I-D on EPP over SOAP
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "McGarry, Tom" <[email-masked]>, "Wilhelm, Richard" <[email-masked]>, "Zhang, Ning" <[email-masked]>
To: "Liu, Hong" <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Sender: [email-masked]

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.

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "McGarry, Tom" <[email-masked]>, "Wilhelm, Richard" <[email-masked]>, "Zhang, Ning" <[email-masked]>, "Liu, Hong" <[email-masked]>
Subject: RE: New I-D on EPP over SOAP
Date: Thu, 26 Sep 2002 11:51:24 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Thursday, September 26, 2002 1:26 AM
To: Liu, Hong
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; 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

Date: Thu, 26 Sep 2002 07:25:52 +0200
Subject: Re: New I-D on EPP over SOAP
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "McGarry, Tom" <[email-masked]>, "Wilhelm, Richard" <[email-masked]>, "Zhang, Ning" <[email-masked]>
To: "Liu, Hong" <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Sender: [email-masked]

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

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "McGarry, Tom" <[email-masked]>, "Wilhelm, Richard" <[email-masked]>, "Zhang, Ning" <[email-masked]>, "Liu, Hong" <[email-masked]>
Subject: New I-D on EPP over SOAP
Date: Wed, 25 Sep 2002 15:52:35 -0400
Sender: [email-masked]

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

Date: Thu, 19 Sep 2002 12:56:49 -0400
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: preparing for Atlanta (already?)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: EPP client now posted
Date: Tue, 17 Sep 2002 13:29:30 -0400
Importance: Normal
Sender: [email-masked]

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

To: IETF-Announce: ;
Subject: RFC 3375 on Generic Registry-Registrar Protocol Requirements
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 16 Sep 2002 16:59:22 -0700
Sender: [email-masked]

--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:    [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

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

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

--OtherAccess--
--NextPart--

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: "status" element in <domain:info> response
Date: Thu, 12 Sep 2002 13:09:30 -0400
Sender: [email-masked]

Thanks, Scott. That will do it.

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, September 11, 2002 2:20 PM
To: 'Liu, Hong'; [email-masked]'
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-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 14:20:06 -0400
Sender: [email-masked]

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

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, Asbjorn Steira <[email-masked]>, [email-masked], [email-masked]
Subject: Re: dcp expiry element 
Date: Wed, 11 Sep 2002 10:59:14 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 10:54:54 -0400
Sender: [email-masked]

Scott, please see my comments below. 

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, September 11, 2002 9:48 AM
To: 'Liu, Hong'; [email-masked]'
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-

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: email datatype definition in Contact -05
Date: Wed, 11 Sep 2002 09:57:54 -0400
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, September 11, 2002 9:54 AM
To: 'Liu, Hong'; [email-masked]'
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-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: email datatype definition in Contact -05
Date: Wed, 11 Sep 2002 09:54:09 -0400
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 09:48:15 -0400
Sender: [email-masked]

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

Date: Wed, 11 Sep 2002 14:27:41 +0100
From: Asbjorn Steira <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: dcp expiry element
Sender: [email-masked]

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

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 09:19:59 -0400
Sender: [email-masked]

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

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: email datatype definition in Contact -05
Date: Wed, 11 Sep 2002 09:04:40 -0400
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, Asbjorn Steira <[email-masked]>
Cc: [email-masked]
Subject: RE: dcp expiry element 
Date: Wed, 11 Sep 2002 08:34:00 -0400
Sender: [email-masked]

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

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

-Scott-

To: Asbjorn Steira <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: dcp expiry element 
Date: Wed, 11 Sep 2002 08:16:51 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Asbjorn Steira'" <[email-masked]>, [email-masked]
Subject: RE: dcp expiry element
Date: Wed, 11 Sep 2002 08:13:09 -0400
Sender: [email-masked]

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

Date: Wed, 11 Sep 2002 11:41:48 +0100
From: Asbjorn Steira <[email-masked]>
To: [email-masked]
Subject: dcp expiry element
Sender: [email-masked]

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

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-provreg-epp-07.txt, 5. Internationalization Consid erations 
Date: Tue, 10 Sep 2002 11:51:38 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-provreg-epp-07.txt, 5. Internationalization Consid erations
Date: Tue, 10 Sep 2002 11:12:28 -0400
Sender: [email-masked]

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

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

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

To: Dave Crocker <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Edmon Chung" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: epp via smtp 
Date: Sun, 08 Sep 2002 22:15:33 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

Date: Sat, 07 Sep 2002 13:38:11 -0700
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: epp via smtp 
Cc: [email-masked]
Sender: [email-masked]

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:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

To: Dave Crocker <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Edmon Chung" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: epp via smtp 
Date: Sat, 07 Sep 2002 13:33:19 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

To: Dave Crocker <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Edmon Chung" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: epp via smtp 
Date: Sat, 07 Sep 2002 13:32:05 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

I can't help you on matters of faith.

Date: Sat, 07 Sep 2002 10:26:12 -0700
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: epp via smtp 
Cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Edmon Chung" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

Date: Sat, 07 Sep 2002 10:01:10 -0700
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: epp via smtp 
Cc: "Edmon Chung" <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

To: Dave Crocker <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Edmon Chung" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: epp via smtp 
Date: Sat, 07 Sep 2002 13:05:39 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> convert SMTP sessions???

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

Date: Sat, 07 Sep 2002 09:43:19 -0700
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: epp via smtp 
Cc: "Edmon Chung" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

To: "Edmon Chung" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: epp via smtp 
Date: Sat, 07 Sep 2002 09:04:39 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

To: "Edmon Chung" <[email-masked]>
cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: epp via smtp 
Date: Fri, 06 Sep 2002 21:11:52 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

From: "Edmon Chung" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: epp via smtp 
Date: Fri, 6 Sep 2002 18:18:54 -0400
Sender: [email-masked]

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

To: "Edmon Chung" <[email-masked]>
cc: [email-masked]
Subject: Re: epp via smtp 
Date: Fri, 06 Sep 2002 17:28:29 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

From: "Edmon Chung" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>, "Edward Lewis" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: epp via smtp
Date: Fri, 6 Sep 2002 12:44:17 -0400
Sender: [email-masked]

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" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; "Eric Brunner-Williams in Portland
Maine" <[email-masked]>
Cc: "Edward Lewis" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
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:[email-masked]>
> >TribalWise, Inc. <http://www.tribalwise.com>
> >tel +1.408.246.8253; fax +1.408.850.1850
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          +1-703-227-9854
> ARIN Research Engineer
>
>

Date: Fri, 6 Sep 2002 09:55:04 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Request to Move RFC 954 to Historic Status
Organization: NIC France
Sender: [email-masked]

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

To: Jaap Akkerhuis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Request to Move RFC 954 to Historic Status 
Date: Thu, 05 Sep 2002 16:41:46 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Request to Move RFC 954 to Historic Status 
Date: Thu, 05 Sep 2002 22:01:09 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    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

Date: Thu, 5 Sep 2002 14:12:33 -0400
Subject: Re: Request to Move RFC 954 to Historic Status
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: "Derek J. Balling" <[email-masked]>
Sender: [email-masked]

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  |
| [email-masked]           |  word and a two-by-four, than  |
| www.megacity.org/blog/       |  you can with just a kind      |
|                              |  word."               - Marcus |
+---------------------------------------------------------------+

To: [email-masked], [email-masked], [email-masked], [email-masked]
cc: [email-masked], [email-masked], [email-masked]
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 <[email-masked]>
Sender: [email-masked]

[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: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-brunner-rfc954-historic-00.txt
Date: Thu, 05 Sep 2002 07:18:36 -0400
Sender: [email-masked]

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

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

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

Date: Thu, 05 Sep 2002 16:49:53 +0100
From: Asbjorn Steira <[email-masked]>
To: Edward Lewis <[email-masked]>
CC: [email-masked]
Subject: Re: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
Sender: [email-masked]

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

Date: Thu, 5 Sep 2002 11:31:15 -0400
To: Asbjorn Steira <[email-masked]>, Edward Lewis <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Thu, 05 Sep 2002 16:21:11 +0100
From: Asbjorn Steira <[email-masked]>
To: Edward Lewis <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
Sender: [email-masked]

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

Date: Thu, 5 Sep 2002 11:05:33 -0400
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: updated milestones
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: updated milestones 
Date: Wed, 04 Sep 2002 20:13:07 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> SEP 02		First draft of EPP over SMTP

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

Date: Wed, 4 Sep 2002 13:28:04 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: updated milestones
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 4 Sep 2002 08:33:36 -0400
To: Dave Crocker <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: epp via smtp
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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:[email-masked]>
>TribalWise, Inc. <http://www.tribalwise.com>
>tel +1.408.246.8253; fax +1.408.850.1850

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 4 Sep 2002 08:29:41 -0400
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: epp via smtp
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Tue, 03 Sep 2002 21:09:41 -0700
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: epp via smtp 
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: epp via smtp 
Date: Tue, 03 Sep 2002 21:07:40 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

Remind me. Who volunteered?

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: epp via smtp
Date: Tue, 3 Sep 2002 20:53:24 -0400 
Sender: [email-masked]

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

Date: Tue, 3 Sep 2002 17:45:38 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: epp via smtp
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Tue, 3 Sep 2002 17:39:51 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: please remove a document from our charter
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

Date: Tue, 3 Sep 2002 17:28:00 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: FW: I-D ACTION:draft-hollenbeck-epp-ext-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Folks,

Do we make this a WG item?

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

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]

>	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                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: preparing for Atlanta (already?) 
Date: Tue, 03 Sep 2002 13:42:17 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

to discuss what?

Date: Tue, 3 Sep 2002 11:55:21 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: preparing for Atlanta (already?)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer