Subject: [ietf-provreg] where we are

From: Edward Lewis <[email-masked]>
Date: Tue, 30 Sep 2003 16:32:50 -0400

(Off the top of my head as September draws to a close...)

It's been nearly 5 months since the IESG has approved our documents 
at the Proposed Standards level.  The documents have moved into the 
RFC Editor's Queue where they have been held up because we reference 
another document.  (The other document was trailing ours, but that 
document has been approved.)

We do have a port number reserved, mail of that was sent out a few weeks ago.

What's next?

Well, the design of the WG is to close down after the documents are 
in the RFC series.  We are hanging around, in form, only to make sure 
there are no hiccups with the publication of the documents.  We have 
no milestones left, we do not plan to meet in Minneapolis.

The mailing list will be available after the WG folds.  And reaching 
Proposed Standard isn't the ultimate goal - the next level is Draft 
Standard.

Draft standard is achieved by meeting criteria in RFC 2026.  There 
are two I want to highlight.

1) A report of interoperability of implementations.  At least two 
completely independent implementations are needed, that's client and 
server, and there has to be a test and report that reports on how 
clear the specifications are.  (That's Client X with Server Y, Client 
Y with Server X.)

This is not a product comparison, it's not important if Client Z is 
broken, it's whether two folks could read the same words and wrote 
code that follows the protocol as intended.  This is a measure of how 
clear the specifications are.  Not a measure of the implementors.

2) There's a 6 month delay between PS and DS - at a minimum.  The 
delay isn't the big hurdle in anyway.  In fact, next week will mark 5 
months since the IESG approved our documents.  I've asked a few folks 
if these 5 months count towards the 6, some answered yes and some 
said it should start with the port number assignment.

Either way, I'm sure the interoperability hurdle is the greater feat.

Those wishing to push this effort towards Draft (and maybe eventually 
Full) Standard ought to keep this points in mind.  What is needed are 
implementations, then testing, and then maybe a proposed BOF/Charter 
to constitute a WG for the next level of review.  There's no reason 
to "wait" because of the RFC 2026 calendar delays.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

Date: Tue, 30 Sep 2003 16:32:50 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] where we are
Cc: [email-masked]
Sender: [email-masked]

(Off the top of my head as September draws to a close...)

It's been nearly 5 months since the IESG has approved our documents 
at the Proposed Standards level.  The documents have moved into the 
RFC Editor's Queue where they have been held up because we reference 
another document.  (The other document was trailing ours, but that 
document has been approved.)

We do have a port number reserved, mail of that was sent out a few weeks ago.

What's next?

Well, the design of the WG is to close down after the documents are 
in the RFC series.  We are hanging around, in form, only to make sure 
there are no hiccups with the publication of the documents.  We have 
no milestones left, we do not plan to meet in Minneapolis.

The mailing list will be available after the WG folds.  And reaching 
Proposed Standard isn't the ultimate goal - the next level is Draft 
Standard.

Draft standard is achieved by meeting criteria in RFC 2026.  There 
are two I want to highlight.

1) A report of interoperability of implementations.  At least two 
completely independent implementations are needed, that's client and 
server, and there has to be a test and report that reports on how 
clear the specifications are.  (That's Client X with Server Y, Client 
Y with Server X.)

This is not a product comparison, it's not important if Client Z is 
broken, it's whether two folks could read the same words and wrote 
code that follows the protocol as intended.  This is a measure of how 
clear the specifications are.  Not a measure of the implementors.

2) There's a 6 month delay between PS and DS - at a minimum.  The 
delay isn't the big hurdle in anyway.  In fact, next week will mark 5 
months since the IESG approved our documents.  I've asked a few folks 
if these 5 months count towards the 6, some answered yes and some 
said it should start with the port number assignment.

Either way, I'm sure the interoperability hurdle is the greater feat.

Those wishing to push this effort towards Draft (and maybe eventually 
Full) Standard ought to keep this points in mind.  What is needed are 
implementations, then testing, and then maybe a proposed BOF/Charter 
to constitute a WG for the next level of review.  There's no reason 
to "wait" because of the RFC 2026 calendar delays.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Cristian Rojas R.'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] EPP and wildcards
Date: Mon, 22 Sep 2003 15:16:07 -0400
Sender: [email-masked]

The data type used to define domain names is defined in section 4.2 of the
EPP core protocol draft.  Look for the "<simpleType name="labelType">"
definition; it uses the XML schema "token" data type.  This XML Schema data
type allows use of the "*" character.

However, section 2.1 of the domain draft requires conformance with RFCs 952
and 1123.  These don't allow the "*" character in domain names.  You could
use the EPP core data type to define a schema of your own for domain
searching, but searching as you described isn't supported in the domain
draft.

-Scott-

> -----Original Message-----
> From: Cristian Rojas R. [mailto:[email-masked]] 
> Sent: Monday, September 22, 2003 11:08 AM
> To: [email-masked]
> Subject: [ietf-provreg] EPP and wildcards
> 
> 
> Hello all:
> 
>     This can be a stupid question, but I don't want to remain 
> with the 
> doubt. Can EPP use wildcards (particularly regular 
> expressions)? I show 
> you an example:
> ...
> C:  <command>
> C:    <check>
> C:      <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
> C:                    
> xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
> C:                    domain-1.0.xsd">
> C:        <domain:name>epp*.tld</domain:name>
> C:      </domain:check>
> C:    </check>
> C:    <clTRID>any-thing</clTRID>
> C:  </command>
> ...
> S:  <response>
> S:     <result code="1000">
> S:        <msg>Command completed successfully</msg>
> S:     </result>
> S:        <resData>
> S:           <domain:chkData 
> xmlns:contact="urn:ietf:params:xml:ns:domain-1.0" 
> xssi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 
> domain-1.0.xsd">
> S:              <domain:cd>
> S:                 <domain:name avail="0">eppXX.tld</domain:name>
> S:                 <domain:reason avail="0">In use</domain:reason> 
> S:              </domain:cd>
> S:              <domain:cd>
> S:                 <domain:name avail="0">eppYY.tld</domain:name>
> S:                 <domain:reason avail="0">In use</domain:reason> 
> S:              </domain:cd>
> S:              <domain:cd>
> S:                 <domain:name avail="0">eppZZ.tld</domain:name>
> S:                 <domain:reason avail="0">In use</domain:reason> 
> S:               </domain:cd>
> ...
> 
>     I'm thinking in the implementation of a whois server based in EPP 
> (for the comunication between whois server an registry's EPP server). 
> This whois must accept regular expressions (just like Afilias 
> whois). I 
> think that is not possible use EPP with RE, but I prefer to ask.
>    
> 
> -- 
> Cristian A. Rojas R. <[email-masked]>   NIC Chile
> Agustinas 1357 4to Piso, Codigo Postal 6500587, Santiago Chile
> Phone: (562) 940 77 00   Fax: (562) 940 77 01
> 

Date: Mon, 22 Sep 2003 11:07:41 -0400
From: "Cristian Rojas R." <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] EPP and wildcards
Sender: [email-masked]

Hello all:

    This can be a stupid question, but I don't want to remain with the 
doubt. Can EPP use wildcards (particularly regular expressions)? I show 
you an example:
...
C:  <command>
C:    <check>
C:      <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C:                    xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
C:                    domain-1.0.xsd">
C:        <domain:name>epp*.tld</domain:name>
C:      </domain:check>
C:    </check>
C:    <clTRID>any-thing</clTRID>
C:  </command>
...
S:  <response>
S:     <result code="1000">
S:        <msg>Command completed successfully</msg>
S:     </result>
S:        <resData>
S:           <domain:chkData 
xmlns:contact="urn:ietf:params:xml:ns:domain-1.0" 
xssi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd">
S:              <domain:cd>
S:                 <domain:name avail="0">eppXX.tld</domain:name>
S:                 <domain:reason avail="0">In use</domain:reason> 
S:              </domain:cd>
S:              <domain:cd>
S:                 <domain:name avail="0">eppYY.tld</domain:name>
S:                 <domain:reason avail="0">In use</domain:reason> 
S:              </domain:cd>
S:              <domain:cd>
S:                 <domain:name avail="0">eppZZ.tld</domain:name>
S:                 <domain:reason avail="0">In use</domain:reason> 
S:               </domain:cd>
...

    I'm thinking in the implementation of a whois server based in EPP 
(for the comunication between whois server an registry's EPP server). 
This whois must accept regular expressions (just like Afilias whois). I 
think that is not possible use EPP with RE, but I prefer to ask.

-- 
Cristian A. Rojas R. <[email-masked]>   NIC Chile
Agustinas 1357 4to Piso, Codigo Postal 6500587, Santiago Chile
Phone: (562) 940 77 00   Fax: (562) 940 77 01

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: [ietf-provreg] Standard EPP Port Number Assigned
Date: Mon, 22 Sep 2003 08:49:43 -0400
Sender: [email-masked]

IANA has assigned standard port numbers for EPP.  Here's the relevant text
from the notice I received:

"We have assigned system port number 700 for epp and
have marked the user port number 3121 as unassigned,
returning it back to IANA.

Please see: <http://www.iana.org/assignments/port-numbers>"

IANA will eventually create a registry for XML namespaces and schemas.  Once
that's done their actions will be completed and the documents will be
further along the RFC publication path.

-Scott-

Reply-To: [email-masked]
From: [email-masked]
To: "Manager" <[email-masked]>
Cc: <[email-masked]>
Subject: GlobalTradeIndex Link - No Charge!       Owe
Date: Sun, 07 Sep 2003 17:38:40 +1200

------=_NextPart_2DB_3965_25339844.F594C273
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_2DB_3965_25339844.F594C273
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

------=_NextPart_2DB_3965_25339844.F594C273--

Reply-To: [email-masked]
From: [email-masked]
To: "Manager" <[email-masked]>
Cc: <[email-masked]>
Subject: Economic Development Network - Link        Kbersvowp
Date: Sat, 06 Sep 2003 12:13:51 +0600

This is a multi-part message in MIME format.

------=_NextPart_892_7897_1B84F93D.C4D7BF66
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_892_7897_1B84F93D.C4D7BF66
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

------=_NextPart_892_7897_1B84F93D.C4D7BF66--