Subject: Re: Revised PROVREG WG minutes - 53rd IETF
From: "Edmon Chung" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Date: Wed, 27 Mar 2002 11:55:08 -0500

Hi,
O... I got momentarily mixed up with implementation of the API with the epp
protocol commands.  My bad. ;-p
Edmon

----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edmon Chung'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 27, 2002 11:12 AM
Subject: RE: Revised PROVREG WG minutes - 53rd IETF

> > -----Original Message-----
> > From: Edmon Chung [mailto:[email-masked]]
> > Sent: Wednesday, March 27, 2002 10:52 AM
> > To: Scott Rose; [email-masked]
> > Subject: Re: Revised PROVREG WG minutes - 53rd IETF
> >
> >
> > Hi Scott,
> > Sorry I didnt respond to the minutes earlier.
> > At the Minneapolis meeting, I did talk about the SG implmentation.
> > Neteka is finalizing the EPP implementation at .sg to be
> > launched in May
> > 2002.
> > One of the issues we faced during the implementation was the
> > need to have
> > multiple statuses for a domain name.  In fact now that I
> > think more about
> > it, I believe this is probably an interesting enough topic that might
> > benefit to be added into the core documents.  The flexibility
> > for multiple
> > statuses means that additional EPP commands is needed to
> > add/delete/edit
> > statuses instead of simply updating the domain info.
> > thoughts everyone?
> > Edmon
>
> Objects like domains can already have multiple status values (several are
> already defined) at the same time, though some values are mutually
> exclusive.  I don't understand the problem as you've described it so
please
> provide more detail.
>
> -Scott-
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edmon Chung'" <[email-masked]>, [email-masked]
Subject: RE: Revised PROVREG WG minutes - 53rd IETF
Date: Wed, 27 Mar 2002 11:12:32 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Edmon Chung [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2002 10:52 AM
> To: Scott Rose; [email-masked]
> Subject: Re: Revised PROVREG WG minutes - 53rd IETF
> 
> 
> Hi Scott,
> Sorry I didnt respond to the minutes earlier.
> At the Minneapolis meeting, I did talk about the SG implmentation.
> Neteka is finalizing the EPP implementation at .sg to be 
> launched in May
> 2002.
> One of the issues we faced during the implementation was the 
> need to have
> multiple statuses for a domain name.  In fact now that I 
> think more about
> it, I believe this is probably an interesting enough topic that might
> benefit to be added into the core documents.  The flexibility 
> for multiple
> statuses means that additional EPP commands is needed to 
> add/delete/edit
> statuses instead of simply updating the domain info.
> thoughts everyone?
> Edmon

Objects like domains can already have multiple status values (several are
already defined) at the same time, though some values are mutually
exclusive.  I don't understand the problem as you've described it so please
provide more detail.

-Scott-

From: "Edmon Chung" <[email-masked]>
To: "Scott Rose" <[email-masked]>, <[email-masked]>
Subject: Re: Revised PROVREG WG minutes - 53rd IETF
Date: Wed, 27 Mar 2002 10:51:45 -0500
Sender: [email-masked]

Hi Scott,
Sorry I didnt respond to the minutes earlier.
At the Minneapolis meeting, I did talk about the SG implmentation.
Neteka is finalizing the EPP implementation at .sg to be launched in May
2002.
One of the issues we faced during the implementation was the need to have
multiple statuses for a domain name.  In fact now that I think more about
it, I believe this is probably an interesting enough topic that might
benefit to be added into the core documents.  The flexibility for multiple
statuses means that additional EPP commands is needed to add/delete/edit
statuses instead of simply updating the domain info.
thoughts everyone?
Edmon

----- Original Message -----
From: "Scott Rose" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 27, 2002 9:19 AM
Subject: Revised PROVREG WG minutes - 53rd IETF

> I got everyone's comments, and made the corrections.  Here is the
> (final?) version of the minutes.  I will submit them to [email-masked]
> by the end of the week.
>
> Thanks for the comments everyone,
> Scott Rose
>
>
>
> PROVREG Meeting minutes
> Taken by Scott Rose ([email-masked])
>
> 1. WG status (Ed Lewis)
>  - Core Documents:  In IESG process in various stages
>  - Other documents - no discussion
>  - 1 Unsolicited individual submission
>  - Next target:  move core drafts to draft standard as per RFC 2026
>    1.  Patrik F:  We need 2 independent client and 2 servers to test
> interop.
>     (all must work together)
>
>
> 2. Last Call Comments on EPP drafts (Scott Hollenbeck)
>  - Requirements Draft:
>   1. WG last call completed
>   2. Comments by IESG in Feb, completed in Feb.
>   3. Waiting IESG
>  - EPP core drafts
>   1. Last call ends 29 March - few comments for additions or corrections
>  - Questions
> Patrik:  IESG or AD has not received any more comments than those
> mentioned in the meeting.
>
>
> 3. In-process documents
>  - BEEP - new revision available in the future.
>   1. Comment:  Is anyone planning any implementation on this draft?
>  - Container draft - will not be continued.
>  - SMTP draft - Still being worked on (rumor).  Some interest in seeing
> this as a draft.
>  - Push feature draft - missing description document.  No one has
>    responsibility for that draft.  If Push feature is desired, please
> submit an
>    individual submission draft.
>
> 4. Implementations (about 5 )
>  - RTK (Sourceforge project) release Java version of registry tool
>   1. Different releases for different levels of EPP(draft revisions) -
> plan on
>      restructuring releases into one package
>  - Melbourne IT (for AusRegistry work) (B. Tonkin):  .au registry
> release (also a Sourceforge project).
>   1. Does contain implementation specific extensions (differs from .us
> extensions)
>   2. first country code to use EPP
>  - Verisign (S. Hollenbeck).
>   1. Non-core effort (smaller domains)  using EPP for registry
>   2. When EPP reaches RFC status, .com/net/org will go to EPP
>   3. Registry (Verisign) will not hold customer information/contact.
> That will still
>      reside at the registrar level.
>   4. All RRP based registration systems will eventually migrate to EPP
> once contract expires
>  - .sg registry
>   1. assumed that one status for domain name
>  - NIC Mexico (F. Arias):
>   1. looking at rolling EPP out.  But using other means to authenticate
> the registrant.  Either using the registrar and EPP (with some further
> security functionality like PKI) or some other authentication protocol
> (not relying on EPP).
>
> 5. Registry-specific extensions (H. Liu)
>  - .us TLD implementation for public review
>  - Informational - may not be WG draft, but informational as an
> extension to EPP.  Test to
>    see if EPP really is extensible and still remain interpretational.
>  - Differences from draft specs:
>   1. Collect NEXUS info for usTLD registration
>   2. 2 new parameters:  AppPurpose and NexusCatagory
>  - Alternatives:  Name-value pairs or new XML schema definition
>  - Comments:
>   1. Where scheme modified?  ContactObject extension field
>
> 6. Scott H.  draft on EPP and DNSSEC/ENUM an individual submission, but
> belongs/will
>    remain independent submission (not DNSEXT) and hoped to be
>    included in DNSOP WG
>  -
> http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-00.txt
>
> 7. Next Steps
>  - Need for a BCP/Informational RFC on how these extensions should
> look?
>   1. moved to list
>  - Interoperability test:  of core protocol specs, not extensions.
>   1. When:  wait until we get RFC status  -  winner
>  - No BEEP/SMTP comments
>
> General comments/questions
> 1. if we start talking about extensions - rechartering necessary?
> 2. Question of "status of command" request message - what it means and
> the status of the draft.
>    - Original poser of the question not present, so no further progress
> on debate could be made - Scott Hollenbeck gave some explination of the
> status of the draft (on hold).
>

Date: Wed, 27 Mar 2002 09:19:46 -0500
From: Scott Rose <[email-masked]>
Organization: NIST
To: [email-masked]
Subject: Revised PROVREG WG minutes - 53rd IETF
Sender: [email-masked]

I got everyone's comments, and made the corrections.  Here is the
(final?) version of the minutes.  I will submit them to [email-masked]
by the end of the week.

Thanks for the comments everyone,
Scott Rose

PROVREG Meeting minutes
Taken by Scott Rose ([email-masked])
 
1. WG status (Ed Lewis)
 - Core Documents:  In IESG process in various stages
 - Other documents - no discussion
 - 1 Unsolicited individual submission
 - Next target:  move core drafts to draft standard as per RFC 2026
   1.  Patrik F:  We need 2 independent client and 2 servers to test
interop.  
    (all must work together)

2. Last Call Comments on EPP drafts (Scott Hollenbeck)
 - Requirements Draft: 
  1. WG last call completed
  2. Comments by IESG in Feb, completed in Feb.
  3. Waiting IESG
 - EPP core drafts
  1. Last call ends 29 March - few comments for additions or corrections
 - Questions
Patrik:  IESG or AD has not received any more comments than those
mentioned in the meeting.

3. In-process documents
 - BEEP - new revision available in the future.
  1. Comment:  Is anyone planning any implementation on this draft?
 - Container draft - will not be continued.
 - SMTP draft - Still being worked on (rumor).  Some interest in seeing
this as a draft.
 - Push feature draft - missing description document.  No one has 
   responsibility for that draft.  If Push feature is desired, please
submit an
   individual submission draft.  
 
4. Implementations (about 5 )
 - RTK (Sourceforge project) release Java version of registry tool 
  1. Different releases for different levels of EPP(draft revisions) -
plan on 
     restructuring releases into one package
 - Melbourne IT (for AusRegistry work) (B. Tonkin):  .au registry
release (also a Sourceforge project).  
  1. Does contain implementation specific extensions (differs from .us
extensions)
  2. first country code to use EPP
 - Verisign (S. Hollenbeck).
  1. Non-core effort (smaller domains)  using EPP for registry
  2. When EPP reaches RFC status, .com/net/org will go to EPP
  3. Registry (Verisign) will not hold customer information/contact. 
That will still 
     reside at the registrar level.
  4. All RRP based registration systems will eventually migrate to EPP
once contract expires
 - .sg registry
  1. assumed that one status for domain name
 - NIC Mexico (F. Arias):  
  1. looking at rolling EPP out.  But using other means to authenticate
the registrant.  Either using the registrar and EPP (with some further
security functionality like PKI) or some other authentication protocol
(not relying on EPP).
 
5. Registry-specific extensions (H. Liu)
 - .us TLD implementation for public review
 - Informational - may not be WG draft, but informational as an
extension to EPP.  Test to 
   see if EPP really is extensible and still remain interpretational.
 - Differences from draft specs:
  1. Collect NEXUS info for usTLD registration
  2. 2 new parameters:  AppPurpose and NexusCatagory
 - Alternatives:  Name-value pairs or new XML schema definition
 - Comments:
  1. Where scheme modified?  ContactObject extension field  
 
6. Scott H.  draft on EPP and DNSSEC/ENUM an individual submission, but
belongs/will 
   remain independent submission (not DNSEXT) and hoped to be
   included in DNSOP WG
 -
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-00.txt
 
7. Next Steps
 - Need for a BCP/Informational RFC on how these extensions should
look?  
  1. moved to list
 - Interoperability test:  of core protocol specs, not extensions.
  1. When:  wait until we get RFC status  -  winner
 - No BEEP/SMTP comments
 
General comments/questions
1. if we start talking about extensions - rechartering necessary?
2. Question of "status of command" request message - what it means and
the status of the draft.
   - Original poser of the question not present, so no further progress
on debate could be made - Scott Hollenbeck gave some explination of the
status of the draft (on hold).

Date: Fri, 22 Mar 2002 15:17:59 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Containers
Cc: [email-masked]
Sender: [email-masked]

During the meeting at Minneapolis it became apparent that no one in the
room, including the editors of the document, continues to support the
document.  The question before the list is, should work on the containers
draft continue AND are the interested parties willing to take on the
editorship responsibilities?

Unless someone speaks up positively, the draft will be removed as a WG item
sometime before the next IETF meeting.

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

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>, [email-masked]
Subject: RE: DCP
Date: Thu, 21 Mar 2002 07:36:49 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Daniel Manley [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 6:35 PM
> To: [email-masked]
> Subject: DCP
> 
> 
> Hi everyone,
> 
> I was curious which registries plan on implementing DCP in 
> the EPP greeting?

It's still TBD in com/net/org.  We're still doing our product planning and
requirements analysis to support the development effort.

-Scott-

Date: Wed, 20 Mar 2002 17:35:16 -0600
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: DCP
Sender: [email-masked]

Hi everyone,

I was curious which registries plan on implementing DCP in the EPP greeting?

Dan

To: Scott Rose <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Minn provreg meeting notes 
Date: Wed, 20 Mar 2002 18:28:11 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

thanks scott. normally that's "gov't inaction".

Date: Wed, 20 Mar 2002 17:55:09 -0500
From: Scott Rose <[email-masked]>
Organization: NIST
To: [email-masked]
Subject: Minn provreg meeting notes
Sender: [email-masked]

Here's the first draft of the meeting minutes from the PROVREG WG. 
Please send any corrections/comments to me.  If none, the minutes will
be submitted to the meeting proceedings.

Gov't in action ;-)
Scott R.

************************************************************************
Provreg Meeting minutes
 
1. WG status (Ed Lewis)
 - Core Documents:  In IESG process in various stages
 - Other documents - no discussion
 - 1 Unsolicited individual submission
 - Next target:  move core drafts to draft standard as per RFC 2026
   1.  Patrik F:  We need 2 independent client and 2 servers to test
interop.  
    (all must work together)

2. Last Call Comments on EPP drafts (Scott Hollenbeck)
 - Requirements Draft: 
  1. WG last call completed
  2. Comments by IESG in Feb, completed in Feb.
  3. Waiting IESG
 - EPP core drafts
  1. Last call ends 29 March - few comments for additions or corrections
 - Questions
Patrik:  IESG or AD has not received any more comments than those
mentioned in the meeting.

3. In-process documents
 - BEEP - new revision available in the future.
  1. Comment:  Is anyone planning any implementation on this draft?
 - Container draft - will not be continued.
 - SMTP draft - Still being worked on (rumor).  Some interest in seeing
this as a draft.
 - Push feature draft - missing description document.  No one has 
   responsibility for that draft.  If Push feature is desired, please
submit an
   individual submission draft.  
 
4. Implementations (about 5 )
 - RTK (Sourceforge project) release Java version of registry tool 
  1. Different releases for different levels of EPP(draft revisions) -
plan on 
     restructuring releases into one package
 - Nominum:  .au registry release.  
  1. Adding different extensions than listed in draft
  2. first country code to use EPP
 - Verisign
  1. Non-core effort (smaller domains)  using EPP for registry
  2. When EPP reaches RFC status, .com/net/org will go to EPP
  3. Registry (Verisign) will not hold customer information/contact. 
That will still 
     reside at the registrar level.
  4. All RRP based registration systems will eventually migrate to EPP
once contract expires
 - .sg registry
  1. assumed that one status for domain name
 - NIC Mexico:  
  1. looking at rolling EPP out.  But using other means to authenticate
registrar-registrar 
     communication
 
5. Registry-specific extensions (H. Liu)
 - .us TLD implementation for public review
 - Informational - may not be WG draft, but informational as an
extension to EPP.  Test to 
   see if EPP really is extensible and still remain interpretational.
 - Differences from draft specs:
  1. Collect NEXUS info for usTLD registration
  2. 2 new parameters:  AppPurpose and NexusCatagory
 - Alternatives:  Name-value pairs or new XML schema definition
 - Comments:
  1. Where scheme modified?  ContactObject extension field  
 
6. Scott H.  draft on EPP and DNSSEC/ENUM an individual submission, but
belongs/will 
   remain independent submission (not DNSEXT) and hoped to be
   included in DNSOP WG
 -
http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-00.txt
 
7. Next Steps
 - Need for a BCP/Informational RFC on how these extensions should
look?  
  1. moved to list
 - Interoperability test:  of core protocol specs, not extensions.
  1. When:  wait until we get RFC status  -  winner
 - No BEEP/SMTP comments
 
General comments/questions
1. if we start talking about extensions - rechartering necessary?
2. Question of "status of command" request message - what it means and
the status of the draft.
   - Author not present, so no formal answer available.

Date: Tue, 12 Mar 2002 16:39:52 -0500
To: [email-masked], [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Provreg agenda for Minneapolis
Cc: [email-masked]
Sender: [email-masked]

1 WG status (Ed Lewis)

2 Last Call Comments (Scott Hollenbeck)
http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-06.txt
  and
http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00026.html
  referring to the following
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-04.txt

3 In Process Documents (Authors of those)
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-beep-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-container-01.txt

4 Implementations (Few minutes from those wanting to report)

5 Registry-Specific Extensions (Hong Liu)
http://www.ietf.org/internet-drafts/draft-liu-epp-ustld-00.txt

6 WG Next Steps
Discussion...

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

Do you have the time to listen to me whine
About nothing and everything all at once?
-- Green Day ("Basket Case")

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

Date: Tue, 12 Mar 2002 07:45:45 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Agenda?
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Good Sugggestion...that should be #6 on the agenda.

At 9:28 PM -0500 3/11/02, Hollenbeck, Scott wrote:
>Ed,
>
>Maybe we ought to spend some time discussing "next steps"?  Should we
>declare victory and go home assuming the last call docs advance, or are
>there other things to do with interop testing, docs for the address
>registries etc?

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

Do you have the time to listen to me whine
About nothing and everything all at once?
-- Green Day ("Basket Case")

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

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Agenda? 
Date: Tue, 12 Mar 2002 12:40:07 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Maybe we ought to spend some time discussing "next steps"?  Should we
> declare victory and go home assuming the last call docs advance, or are

works for me. we know we're not going to get consensus on:

	o transport other than conection-oriented, synchronous,
	o event/state model other than client-server,
	o abstractions or groupings of operations,
	o national requirements,
	o other

> there other things to do with interop testing,

not strictly required, as a process issue. the existing installed base
appears to have exhausted this requirement, not to mention themselves.

>                                                docs for the address
> registries etc?

upon mature reflection, i think i erred in thinking that this wg could
meet the RIR and dependent needs. there's a lot of generic tld industry
explicit and implicit conditions in what we've managed to accomplish,
reflecting the material interests of the core contributors.

recently in another venue i've been confronted by the assumption that
this wg would be the natural place for key word provisioning to go. for
some values of "key word systems", the material conditions (r-star roles,
costs, etc.) are similar to (replicate or incorporate) the icann domain
name registration industry, but not the national domain name registries.

in theory, yeah, its just state with a aaa model ... this wg could make
a thing as generally useful as nfs or beep or ldap, but ...

in practice oil and water. gtlds and cctlds do not mix. tlds and slds do
not mix. domains and addresses do not mix. domains and keywords probably
should not mix (to their mutual benefit, not to mention the iesg).

i suggest we return all non-LC'd drafts to their authors as individual
submissions, wind down, and let the r-star players go their merry ways.

declare victory, go home, works for me.
eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: Agenda?
Date: Mon, 11 Mar 2002 21:28:15 -0500
Sender: [email-masked]

Ed,

Maybe we ought to spend some time discussing "next steps"?  Should we
declare victory and go home assuming the last call docs advance, or are
there other things to do with interop testing, docs for the address
registries etc?

-Scott-

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Monday, March 11, 2002 3:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Agenda?
> 
> 
> In lieu of a more formal agenda, I propose this one.
> 
> 1 WG status (Ed Lewis)
> 2 Last Call Comments (Scott Hollenbeck)
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-re
> qs-06.txt
>   and
> http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00026.html
>   referring to the following
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-06.txt
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-dom
> ain-04.txt
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-con
> tact-04.txt
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-04.txt
> 3 In Process Documents (Authors of those)
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-beep-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-con
> tainer-01.txt
> 4 Implementations (Few minutes from those wanting to report)
> 5 Registry-Specific Extensions (Hong Liu)
> http://www.ietf.org/internet-drafts/draft-liu-epp-ustld-00.txt
> 
> If I don't hear from anyone, I'll send this to agenda@ tomorrow.
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
> 
> Do you have the time to listen to me whine
> About nothing and everything all at once?
> -- Green Day ("Basket Case")
> 
> Opinions expressed are property of my evil twin, not my employer.
> 

Date: Mon, 11 Mar 2002 15:21:12 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Agenda?
Cc: [email-masked]
Sender: [email-masked]

In lieu of a more formal agenda, I propose this one.

1 WG status (Ed Lewis)
2 Last Call Comments (Scott Hollenbeck)
http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-06.txt
  and
http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00026.html
  referring to the following
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-04.txt
3 In Process Documents (Authors of those)
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-beep-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-container-01.txt
4 Implementations (Few minutes from those wanting to report)
5 Registry-Specific Extensions (Hong Liu)
http://www.ietf.org/internet-drafts/draft-liu-epp-ustld-00.txt

If I don't hear from anyone, I'll send this to agenda@ tomorrow.

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

Do you have the time to listen to me whine
About nothing and everything all at once?
-- Green Day ("Basket Case")

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Some EPP Last Call Comments
Date: Fri, 8 Mar 2002 21:45:23 -0500 
Sender: [email-masked]

After the provreg WG's EPP documents finished WG last call, but before the
IESG's last call was issued, I received word of a few defects that should be
fixed and also a few requests for additions.  Here are links to the comments
made publicly, and text for those I received privately:

1. Category: Fix
http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00032.html

In the epp-06 schema, this:

<element name="clTRID" type="epp:trIDStatusType"
 minOccurs="0"/>

should be changed to this:

<element name="clTRID" type="epp:trIDStatusType"
 minOccurs="0" maxOccurs="unbounded"/>

This will allow more than one element as described in the text.

2. Category: Fix
http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00004.html

In the domain-04 schema, this element in the <info> response:

<element name="registrant" type="domain:contactType"
 minOccurs="0"/>

should be changed to this:

<element name="registrant" type="eppcom:clIDType"
 minOccurs="0"/>

This will make the data type correct in the <info> response.

3. Category: Requested Additions
http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00006.html

A request to add an additional response code, additional statuses, and
explanatory text.

4. Category: Fix and Requested Addition
http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00013.html

A fix to increase the length of the contact-04 postal code field from 10 to
16 characters, and a request to add an OPTIONAL field to better help explain
server error conditions.

5. Category: Documentation
I received a private suggestion to number document paragraphs that describe
elements in addition to indenting them to better help identify parent-child
relationships.

6. Category: Requested Addition
Patrik suggested a modification to the object <authInfo> structure such that
authentication mechanisms other than passwords could be defined in the
future without requiring change to an existing schema.  This can be done by
changing the <authInfo> data types slightly to accommodate namespace
extensions.

-Scott-

Date: Fri, 8 Mar 2002 15:25:52 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Patrick <[email-masked]>
cc: Olafur Osvaldsson <[email-masked]>, James Woods <[email-masked]>, <[email-masked]>
Subject: Re: Open Source Server Implementation
Sender: [email-masked]

basic fusion puchaed by new.net ?!?

see
http://www.prnewswire.com/cgi-bin/micro_stories.pl?ACCT=156973&TICK=NEWN&STORY=/www/story/02-28-2002/0001677927&EDATE=Feb%2B28,%2B2002

-rick

On Fri, 8 Mar 2002, Patrick wrote:

> On Fri, 8 Mar 2002, Olafur Osvaldsson wrote:
>
> >
> >
> > On Mon, 07 Jan 2002, James Woods wrote:
> >
> > > Hi Scott,
> > >
> > > We have two EPP implementation services that we plan to launch soon,
> > > (the openess is under debate right now but I think I'll win this one ;)
> > > one is a modified client (ala GUI) called CuteEPP the other EPPserv.
> > > Regardless of whether these get "opened" or not our dev team would love
> > > to hook up with others wishing to do so.
> > >
> >
> > Any news on this, did you win?  :)
>
> They(Basic Fusion) got bought.
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>                                Patrick Greenwell
>          Asking the wrong questions is the leading cause of wrong answers
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
>

Date: Fri, 8 Mar 2002 15:15:29 -0800 (PST)
From: Patrick <[email-masked]>
To: Olafur Osvaldsson <[email-masked]>
cc: James Woods <[email-masked]>, <[email-masked]>
Subject: Re: Open Source Server Implementation
Sender: [email-masked]

On Fri, 8 Mar 2002, Olafur Osvaldsson wrote:

>
>
> On Mon, 07 Jan 2002, James Woods wrote:
>
> > Hi Scott,
> >
> > We have two EPP implementation services that we plan to launch soon,
> > (the openess is under debate right now but I think I'll win this one ;)
> > one is a modified client (ala GUI) called CuteEPP the other EPPserv.
> > Regardless of whether these get "opened" or not our dev team would love
> > to hook up with others wishing to do so.
> >
>
> Any news on this, did you win?  :)

They(Basic Fusion) got bought.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                               Patrick Greenwell
         Asking the wrong questions is the leading cause of wrong answers
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Date: Fri, 8 Mar 2002 21:52:13 +0000
From: Olafur Osvaldsson <[email-masked]>
To: James Woods <[email-masked]>
Cc: [email-masked]
Subject: Re: Open Source Server Implementation
Sender: [email-masked]

On Mon, 07 Jan 2002, James Woods wrote:

> Hi Scott,
> 
> We have two EPP implementation services that we plan to launch soon,
> (the openess is under debate right now but I think I'll win this one ;)
> one is a modified client (ala GUI) called CuteEPP the other EPPserv.
> Regardless of whether these get "opened" or not our dev team would love
> to hook up with others wishing to do so.
> 

Any news on this, did you win?  :)

	Oli

-- 
Olafur Osvaldsson
Systems Administrator
Internet a Islandi hf.
Tel:   +354 525-5291
Email: [email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Extensible Provisioning Protocol to Proposed Standard
Reply-to: [email-masked]
Date: Fri, 08 Mar 2002 15:29:14 -0500
Sender: [email-masked]

The IESG has received a request from the Provisioning Registry Protocol
Working Group to consider publication of the following Internet-Drafts
as Proposed Standards:

 o Extensible Provisioning Protocol
	<draft-ietf-provreg-epp-06.txt> 
 o Extensible Provisioning Protocol Domain Name Mapping
	<draft-ietf-provreg-epp-domain-04.txt>
 o Extensible Provisioning Protocol Host Mapping
	<draft-ietf-provreg-epp-host-04.txt> 
 o Extensible Provisioning Protocol Contact Mapping
	<draft-ietf-provreg-epp-contact-04.txt>
 o Extensible Provisioning Protocol Transport Over TCP
	<draft-ietf-provreg-epp-tcp-04.txt>

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by March 29, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-04.txt

To: "Liu, Hong" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Additional Response Code and Status Code for EPP 
Date: Fri, 08 Mar 2002 13:00:11 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

This seems appropos, from the Portland Pattern Repository (de facto home
of the extreme programming discipline), hosted by Cunningham & Cunningham.

	"Life's too short to write code that nobody wants."

I'm not going to put conditional in my implementation, either there exists
a right-to-publish (register) or there exists a right-to-retract (modify).

Conditional completions (keywords: speculation,lottery,lazy evaluation)
are for those who have the requirment. It isn't general, and shouldn't
be in EPP.

Eric

Reply-To: <[email-masked]>
From: "Michael Young" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>, <[email-masked]>
Subject: RE: Some More Off-List Comments
Date: Thu, 7 Mar 2002 16:42:41 -0500
Organization: Liberty RMS
Importance: Normal
Sender: [email-masked]

I agree with Dan in that registrars are always well-advised to improve
their level of quality control (as is everyone), but I believe firmly
that the availibility of an optional tag such as this is going to help
that process immensely.  In view of someone who operates a registry, I
believe we could do a much better job of helping the registrars be
successful with this option.  At the end of the day we are here to help
registrars regardless; it would only make it faster and easier for
everyone if we can feed them more meaningful information on their errors
in the first place.  

Michael Young
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Daniel Manley
Sent: Thursday, March 07, 2002 3:12 PM
To: [email-masked]
Subject: Re: Some More Off-List Comments

Is all this extra information really needed?  Registrars should be 
validating as much information as possible before sending to the 
registry.  This would weed out 95% of problem data.  To now add reasons 
to values makes the registry hold the registrar's hand where the 
registrar should be smarter than your average registrant.  All of this 
user-friendliness also adds more development burden on the registry.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Daniel Manley [mailto:[email-masked]]
>>Sent: Thursday, March 07, 2002 2:38 PM
>>To: Hollenbeck, Scott
>>Cc: [email-masked]'; [email-masked]
>>Subject: Re: Some More Off-List Comments
>>
>>
>>Shouldn't the "reason" tie in with the array of <values>?
>>Because each 
>>field could have a different reason.
>>
>
>Sure, I suppose it could.
>
>-Scott-
>

From: "Gould, James" <[email-masked]>
To: [email-masked], "'Daniel Manley'" <[email-masked]>
Subject: RE: Some More Off-List Comments
Date: Thu, 7 Mar 2002 16:14:10 -0500 
Sender: [email-masked]

Yes, this extra information is needed.  Many errors generated by the server
business logic are mapped to the EPP result codes, but that is not enough
information for a Registrar or CSR to track down the exact reason for the
error.  If the server knows what caused the error (i.e. "Credit limit has
been exceeded", "foo.com is reserved", "Must have admin contact")
it would be helpful for it to be able to return the reason to the client.
This will save calls to CSR's with errors that are obvious 
from the reason.  The reason can be made optional, so there should be no
impact to existing implementations, and by adding it a substantial amount of
effort will be saved in handling Registrar issues.  

Jim

> ----------
> From: 	Daniel Manley
> Sent: 	Thursday, March 7, 2002 3:12 PM
> To: 	[email-masked]
> Subject: 	Re: Some More Off-List Comments
> 
> Is all this extra information really needed?  Registrars should be 
> validating as much information as possible before sending to the 
> registry.  This would weed out 95% of problem data.  To now add reasons 
> to values makes the registry hold the registrar's hand where the 
> registrar should be smarter than your average registrant.  All of this 
> user-friendliness also adds more development burden on the registry.
> 
> Dan
> 
> 
> Hollenbeck, Scott wrote:
> 
> >>-----Original Message-----
> >>From: Daniel Manley [mailto:[email-masked]]
> >>Sent: Thursday, March 07, 2002 2:38 PM
> >>To: Hollenbeck, Scott
> >>Cc: [email-masked]'; [email-masked]
> >>Subject: Re: Some More Off-List Comments
> >>
> >>
> >>Shouldn't the "reason" tie in with the array of <values>?  
> >>Because each 
> >>field could have a different reason.
> >>
> >
> >Sure, I suppose it could.
> >
> >-Scott-
> >
> 
> 
> 

From: "Gould, James" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Cc: [email-masked]
Subject: RE: Some More Off-List Comments
Date: Thu, 7 Mar 2002 15:08:39 -0500 
Sender: [email-masked]

I would prefer a less complex alternative of having a freeform "reason" per
error result and not per error value.  Since an error response can contain
multiple error results, and each error result can reference multiple error
element tag/values, it would be simpler to have the "reason" an element of
the error result.  Multiple error results can be used to satisfy the error
reporting requirements.  

Jim

> ----------
> From: 	Hollenbeck, Scott
> Sent: 	Thursday, March 7, 2002 2:36 PM
> To: 	'Daniel Manley'
> Cc: 	[email-masked]
> Subject: 	RE: Some More Off-List Comments
> 
> > -----Original Message-----
> > From: Daniel Manley [mailto:[email-masked]]
> > Sent: Thursday, March 07, 2002 2:38 PM
> > To: Hollenbeck, Scott
> > Cc: [email-masked]'; [email-masked]
> > Subject: Re: Some More Off-List Comments
> > 
> > 
> > Shouldn't the "reason" tie in with the array of <values>?  
> > Because each 
> > field could have a different reason.
> 
> Sure, I suppose it could.
> 
> -Scott-
> 
> 

Date: Thu, 7 Mar 2002 21:03:45 +0100 (MET)
From: Elisabeth Porteneuve <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Some More Off-List Comments
Sender: [email-masked]

The French rules for writing postal address are normalized,
cf. AFNOR XP Z 10-011, May 1997 so called norme 38.
In short:
   6 lignes maximum  
  38 characters maximum per line (including spaces)

The exemple with instructions is given at:
http://preproduction.laposte.fr/sna/saisie/saisiepart.asp

Yes, indeed we have Cedex indications.
Usually Cedex follows city name, something like
        75982 PARIS CEDEX 20
and is NOT a ZIP code
More instructions at:
http://www.laposte.fr/produits/courrier/code.htm

And yes, indeed our ZIP code is on the left side
of the city name - like in almost all continental Europe.

You may note that some European countries add a country prefix
to their ZIP code, but unfortunately this prefix seems
car's plates based, therefore not universal.
It would be much better postal services use ISO 3166-1,
like bank do in their IBAN - International Bank Account Number,
but it is another debate.

I am in favor of 16 characters for ZIP area, rather than 10.
And for postal address respecting countrie's rules
- looking on IANA content for ccTLD is just making me nervous.

Elisabeth Porteneuve
--

-------Original Message---------------------------------------------
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Mike Lampson'" <[email-masked]>,
        "'ietf-provregcafaxse'"
	 <[email-masked]>
Subject: RE: Some More Off-List Comments
Date: Thu, 7 Mar 2002 10:56:51 -0500 

> -----Original Message-----
> From: Mike Lampson [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 10:46 AM
> To: Hollenbeck Scott; 'ietf-provregcafaxse'
> Subject: Re: Some More Off-List Comments
> 
> 
> Scott,
> 
> The Universal Postal Union only lists 5 digit postal codes 
> for both France
> and Mexico.

[snip]

FWIW here's the text of the comment I received from Asbjorn Stiera; I don't
think he'll mind me forwarding it to provide context:

"according to a postcode site (1), Mexico allows a 13 digit postal code 
for their "bulk mail code". In addition, in France it is not uncommon to 
append "CEDEX" to the postcode "for business adresses with special 
delivery arrangements" (1)(2), meaning a French post code can 
potentially have 11 digits (5+" "+5)."

I didn't see these possibilities mentioned on the UPU site, though.

> P.S. Without knowing the specific needs (and future changes) of postal
> identifiers used throughout the world, I would say that a 16 
> character limit
> sounds better than 10.

That was part of Asbjorn's argument as well.

-Scott-

(1)
http://www.magma.ca/~djcl/postcd.txt

(2)
http://www.faqs.org/faqs/culture-french-faq/miscellaneous/section-2.html

Date: Thu, 07 Mar 2002 15:12:19 -0500
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: Some More Off-List Comments
Sender: [email-masked]

Is all this extra information really needed?  Registrars should be 
validating as much information as possible before sending to the 
registry.  This would weed out 95% of problem data.  To now add reasons 
to values makes the registry hold the registrar's hand where the 
registrar should be smarter than your average registrant.  All of this 
user-friendliness also adds more development burden on the registry.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Daniel Manley [mailto:[email-masked]]
>>Sent: Thursday, March 07, 2002 2:38 PM
>>To: Hollenbeck, Scott
>>Cc: [email-masked]'; [email-masked]
>>Subject: Re: Some More Off-List Comments
>>
>>
>>Shouldn't the "reason" tie in with the array of <values>?  
>>Because each 
>>field could have a different reason.
>>
>
>Sure, I suppose it could.
>
>-Scott-
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Some More Off-List Comments
Date: Thu, 7 Mar 2002 14:36:18 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: Daniel Manley [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 2:38 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'; [email-masked]
> Subject: Re: Some More Off-List Comments
> 
> 
> Shouldn't the "reason" tie in with the array of <values>?  
> Because each 
> field could have a different reason.

Sure, I suppose it could.

-Scott-

Date: Thu, 07 Mar 2002 14:37:47 -0500
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Some More Off-List Comments
Sender: [email-masked]

Shouldn't the "reason" tie in with the array of <values>?  Because each 
field could have a different reason.

Dan

Hollenbeck, Scott wrote:

>The <msg> element is used to carry only a specified set of response messages
>used to describe the response codes.  As it was explained to me, the
><reason> element would be optional, and could be used to provide additional
>info that would help a client understand why an error occurred.
>
>For example, if an error response of 2306 (Parameter value policy error) is
>returned, the <msg> element would carry "Parameter value policy error" and
>the <reason> element could be used to explain exactly what the policy
>violation is.  This should be helpful both for clients who are trying to
>understand what went wrong and customer service folks on the server side who
>might have to help debug client problems.
>
>-Scott-
>
>>-----Original Message-----
>>From: Lynette Khirallah [mailto:[email-masked]]
>>Sent: Thursday, March 07, 2002 1:58 PM
>>To: 'Hollenbeck, Scott'; [email-masked]
>>Subject: RE: Some More Off-List Comments
>>
>>
>>is there already a <msg> element in the <result> that is 
>>being used for
>>human-readable error condition explanations? I just checked the latest
>>contact draft and there is a <msg> element in the <result>. 
>>How is this
>><reason> element any different from <msg>?
>>If you do add another text element, can it be optional?
>>
>>thanks,
>>Lynette
>>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Some More Off-List Comments
Date: Thu, 7 Mar 2002 14:05:07 -0500 
Sender: [email-masked]

The <msg> element is used to carry only a specified set of response messages
used to describe the response codes.  As it was explained to me, the
<reason> element would be optional, and could be used to provide additional
info that would help a client understand why an error occurred.

For example, if an error response of 2306 (Parameter value policy error) is
returned, the <msg> element would carry "Parameter value policy error" and
the <reason> element could be used to explain exactly what the policy
violation is.  This should be helpful both for clients who are trying to
understand what went wrong and customer service folks on the server side who
might have to help debug client problems.

-Scott-

> -----Original Message-----
> From: Lynette Khirallah [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 1:58 PM
> To: 'Hollenbeck, Scott'; [email-masked]
> Subject: RE: Some More Off-List Comments
> 
> 
> is there already a <msg> element in the <result> that is 
> being used for
> human-readable error condition explanations? I just checked the latest
> contact draft and there is a <msg> element in the <result>. 
> How is this
> <reason> element any different from <msg>?
> If you do add another text element, can it be optional?
> 
> thanks,
> Lynette

Reply-To: <[email-masked]>
From: "Lynette Khirallah" <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>, <[email-masked]>
Subject: RE: Some More Off-List Comments
Date: Thu, 7 Mar 2002 13:58:01 -0500
Importance: Normal
Sender: [email-masked]

is there already a <msg> element in the <result> that is being used for
human-readable error condition explanations? I just checked the latest
contact draft and there is a <msg> element in the <result>. How is this
<reason> element any different from <msg>?
If you do add another text element, can it be optional?

thanks,
Lynette

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On
> Behalf Of Hollenbeck, Scott
> Sent: Thursday, March 07, 2002 9:26 AM
> To: [email-masked]'
> Subject: Some More Off-List Comments
>
>
> I've received a few more comments for protocol
> fixes/improvements off-list.
> I intend to send these to the IESG when they open the last call:
>
> - Increase the length of the contact postal code field to 16
> characters
> because postal codes longer than 10 characters (the current limit) are
> possible in some countries, such as Mexico and France.  Perhaps list
> participants living or working in those countries can confirm?
>
> - Add a child "reason" text element to the <result> element
> so that error
> conditions can be explained more fully in a server-defined,
> human-readable
> way.
>
> -Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Mike Lampson'" <[email-masked]>, "'ietf-provregcafaxse'" <[email-masked]>
Subject: RE: Some More Off-List Comments
Date: Thu, 7 Mar 2002 10:56:51 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: Mike Lampson [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 10:46 AM
> To: Hollenbeck Scott; 'ietf-provregcafaxse'
> Subject: Re: Some More Off-List Comments
> 
> 
> Scott,
> 
> The Universal Postal Union only lists 5 digit postal codes 
> for both France
> and Mexico.

[snip]

FWIW here's the text of the comment I received from Asbjorn Stiera; I don't
think he'll mind me forwarding it to provide context:

"according to a postcode site (1), Mexico allows a 13 digit postal code 
for their "bulk mail code". In addition, in France it is not uncommon to 
append "CEDEX" to the postcode "for business adresses with special 
delivery arrangements" (1)(2), meaning a French post code can 
potentially have 11 digits (5+" "+5)."

I didn't see these possibilities mentioned on the UPU site, though.

> P.S. Without knowing the specific needs (and future changes) of postal
> identifiers used throughout the world, I would say that a 16 
> character limit
> sounds better than 10.

That was part of Asbjorn's argument as well.

-Scott-

(1)
http://www.magma.ca/~djcl/postcd.txt

(2)
http://www.faqs.org/faqs/culture-french-faq/miscellaneous/section-2.html

Date: Thu, 07 Mar 2002 10:45:37 -0500
From: Mike Lampson <[email-masked]>
Subject: Re: Some More Off-List Comments
To: Hollenbeck Scott <[email-masked]>, "'ietf-provregcafaxse'" <[email-masked]>
Sender: [email-masked]

Scott,

The Universal Postal Union only lists 5 digit postal codes for both France
and Mexico.  Note that the UPU also indicates placement of postal codes when
sending mail.  These 2 countries both place their postal code to the left of
the locality.

Start here:
  http://www.upu.int/publications/en/post_code.shtml
and click on "Addressing formats" to look up information for a specific
country.

Regards,

Mike Lampson
The Registry at Info Avenue, LLC

P.S. Without knowing the specific needs (and future changes) of postal
identifiers used throughout the world, I would say that a 16 character limit
sounds better than 10.

----- Original Message -----
From: "Hollenbeck Scott" <[email-masked]>
To: "'ietf-provregcafaxse'" <[email-masked]>
Sent: Thursday, March 07, 2002 9:26 AM
Subject: Some More Off-List Comments

I've received a few more comments for protocol fixes/improvements off-list.
I intend to send these to the IESG when they open the last call:

- Increase the length of the contact postal code field to 16 characters
because postal codes longer than 10 characters (the current limit) are
possible in some countries, such as Mexico and France.  Perhaps list
participants living or working in those countries can confirm?

- Add a child "reason" text element to the <result> element so that error
conditions can be explained more fully in a server-defined, human-readable
way.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Some More Off-List Comments
Date: Thu, 7 Mar 2002 09:26:06 -0500 
Sender: [email-masked]

I've received a few more comments for protocol fixes/improvements off-list.
I intend to send these to the IESG when they open the last call:

- Increase the length of the contact postal code field to 16 characters
because postal codes longer than 10 characters (the current limit) are
possible in some countries, such as Mexico and France.  Perhaps list
participants living or working in those countries can confirm?

- Add a child "reason" text element to the <result> element so that error
conditions can be explained more fully in a server-defined, human-readable
way.

-Scott-

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Roger Castillo Cortazar'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: EPP schemas and example XML instances. 
Date: Tue, 05 Mar 2002 19:01:43 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> I think Eric Brunner-Williams also has them on an ftp site, but I'll let him
> speak to that if he so chooses.

yup.

ftp://nic-naa.net/pub/epp-ta
user=anonymous, password=<your email is a courtesy>
in pub/epp-ta:
-rw-r--r--  1 1000  0  10485 Jan 26 00:28 epp-06.tar.gz

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Roger Castillo Cortazar'" <[email-masked]>, [email-masked]
Subject: RE: EPP schemas and example XML instances.
Date: Tue, 5 Mar 2002 13:35:38 -0500 
Sender: [email-masked]

I have two places available:

http://www.verisign-grs.com/files/

and

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

I think Eric Brunner-Williams also has them on an ftp site, but I'll let him
speak to that if he so chooses.

-Scott-

> -----Original Message-----
> From: Roger Castillo Cortazar [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 1:03 PM
> To: [email-masked]
> Subject: EPP schemas and example XML instances.
> 
> 
> Hi everybody.
> 
> Where can I get EPP schemas and example XML instances ?
> I've been trynig the ftp sites mentioned in a message from 
> last year, ;-)
> but my ftp client freezes.

Date: Tue, 05 Mar 2002 12:02:47 -0600
To: [email-masked]
From: Roger Castillo Cortazar <[email-masked]>
Subject: EPP schemas and example XML instances.
Sender: [email-masked]

Hi everybody.

Where can I get EPP schemas and example XML instances ?
I've been trynig the ftp sites mentioned in a message from last year, ;-)
but my ftp client freezes.

Do I need something special to get the examples ?

Greetings.

Roger Castillo Cortazar
NIC-Mexico http://www.nic.mx
Top Level Domain .MX

Date: Mon, 04 Mar 2002 22:12:08 -0500
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Additional Response Code and Status Code for EPP
Sender: [email-masked]

That's cool with me.

Dan

Hollenbeck, Scott wrote:

>If no one objects I'll add these to the comments to be sent to the IESG to
>assist them in their review.
>
>-Scott-
>
>>-----Original Message-----
>>From: Liu, Hong [mailto:[email-masked]]
>>Sent: Monday, March 04, 2002 4:04 PM
>>To: [email-masked]'
>>Subject: Additional Response Code and Status Code for EPP
>>
>>
>>Scott,
>>
>>To support the pending update/create feature, we would like to see the
>>following be added to the EPP spec:
>>
>>(1) A new response code for "Command completed successfully; action
>>pending";
>>
>>(2) A "pendingVerification" status for the host and contact 
>>object mappings;
>>
>>(3) A "pendingUpdate" status for the domain, host and contact object
>>mappings;
>>
>>(4) Clarification on pending update that: The requesting 
>>registrar MUST wait
>>for a pending update to be completed before issuing another 
>>update on the
>>same object;
>>
>>(5) Clarification on notification after pending update is completed.
>>
>>Thanks!
>>
>>--Hong
>>
>>Note: Both (1) and (2) for host object mapping have already 
>>been suggested
>>in 
>>http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00038.html
>>
>>
>>
>>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Liu, Hong'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Additional Response Code and Status Code for EPP
Date: Mon, 4 Mar 2002 19:47:13 -0500 
Sender: [email-masked]

If no one objects I'll add these to the comments to be sent to the IESG to
assist them in their review.

-Scott-

> -----Original Message-----
> From: Liu, Hong [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 4:04 PM
> To: [email-masked]'
> Subject: Additional Response Code and Status Code for EPP
> 
> 
> Scott,
> 
> To support the pending update/create feature, we would like to see the
> following be added to the EPP spec:
> 
> (1) A new response code for "Command completed successfully; action
> pending";
> 
> (2) A "pendingVerification" status for the host and contact 
> object mappings;
> 
> (3) A "pendingUpdate" status for the domain, host and contact object
> mappings;
> 
> (4) Clarification on pending update that: The requesting 
> registrar MUST wait
> for a pending update to be completed before issuing another 
> update on the
> same object;
> 
> (5) Clarification on notification after pending update is completed.
> 
> Thanks!
> 
> --Hong
> 
> Note: Both (1) and (2) for host object mapping have already 
> been suggested
> in 
> http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00038.html
> 
> 
> 
> 

To: "Liu, Hong" <[email-masked]>
From: "Asaad Y. Alnajjar   (Millennium Inc.)" <[email-masked]>
Subject: Re: Additional Response Code and Status Code for EPP
Reply-To: [email-masked]
CC: "[email-masked]'" <[email-masked]>
Date: Mon, 4 Mar 2002 14:37:59 -0800
Sender: [email-masked]

Dear All

I need a speaker from IETF to give a presentation on IDNs at our 
upcoming AINC meeting in Tunisia.

http://www.any-dns.com/ainc-tunis.htm

Kindly contact me to coordinate, regards,

Asaad Alnajjar
Exec. Director AINC
CEO Millennium Inc.

From: "Liu, Hong" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Additional Response Code and Status Code for EPP
Date: Mon, 4 Mar 2002 15:03:55 -0600 
Sender: [email-masked]

Scott,

To support the pending update/create feature, we would like to see the
following be added to the EPP spec:

(1) A new response code for "Command completed successfully; action
pending";

(2) A "pendingVerification" status for the host and contact object mappings;

(3) A "pendingUpdate" status for the domain, host and contact object
mappings;

(4) Clarification on pending update that: The requesting registrar MUST wait
for a pending update to be completed before issuing another update on the
same object;

(5) Clarification on notification after pending update is completed.

Thanks!

--Hong

Note: Both (1) and (2) for host object mapping have already been suggested
in 
http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00038.html

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: "registrant" in domain-1.0.xsd
Date: Mon, 4 Mar 2002 08:39:07 -0500 
Sender: [email-masked]

I wonder how that slipped through...

Yes, the type in the <info> response should be fixed such that the
registrant element is of type eppcom:clIDType.  Something else to deal with
at the next editing opportunity.

-Scott- 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, March 04, 2002 6:17 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: "registrant" in domain-1.0.xsd
> 
> 
> Hi,
> 
> whereas "registrant" is defined as
> 
>       <element name="registrant" type="eppcom:clIDType"
>        minOccurs="0"/>
> 
> in both createType and chgType (for updates), it is defined as
> 
>       <element name="registrant" type="domain:contactType"
>        minOccurs="0"/>
> 
> in infDataType. Even though the "type" part of contactType is 
> not required, 
> wouldn't it for consistency be better to have it as 
> eppcom:clIDType in 
> infDataType as well? This will stop anyone from putting 
> anything in the 
> type-part of the field...
> 
> 
> Asbjorn

Date: 4 Mar 2002 11:16:32 -0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: "registrant" in domain-1.0.xsd
Sender: [email-masked]

Hi,

whereas "registrant" is defined as

      <element name="registrant" type="eppcom:clIDType"
       minOccurs="0"/>

in both createType and chgType (for updates), it is defined as

      <element name="registrant" type="domain:contactType"
       minOccurs="0"/>

in infDataType. Even though the "type" part of contactType is not required, 
wouldn't it for consistency be better to have it as eppcom:clIDType in 
infDataType as well? This will stop anyone from putting anything in the 
type-part of the field...

Asbjorn

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

From: "Asaad Y. Alnajjar - Millennium Inc." <[email-masked]>
To: <Undisclosed-Recipient:@host3.onnethosting.com;>
Subject: Seminar Invitation / Registration Form - AINC Tunisia April 2002  RESPONSE REQUESTED -
Date: Sat, 2 Mar 2002 01:19:03 -0800
Organization: Millennium Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C1C188.3DB3EF80
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0012_01C1C188.3DB3EF80"

------=_NextPart_001_0012_01C1C188.3DB3EF80
Content-Type: text/plain;
	charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

New Page 1

------=_NextPart_001_0012_01C1C188.3DB3EF80
Content-Type: text/html;
	charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

<BASE HREF=3D"file://C:\TEMP\">=0A=
=0D<html>

<head>
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 5.0">
<meta name=3D"ProgId" content=3D"FrontPage.Editor.Document">
<title>New Page 1</title>
</head>

<frameset rows=3D"28,*">
  <frame name=3D"header" scrolling=3D"no" noresize target=3D"main">
  <frame name=3D"main" src=3D"http://www.any-dns.com/ainc-tunis.htm" =
target=3D"_blank">
  <noframes>
  <body>

  <p>This page uses frames, but your browser doesn't support them.</p>

  </body>
  </noframes>
</frameset>

</html>

------=_NextPart_001_0012_01C1C188.3DB3EF80--

------=_NextPart_000_0011_01C1C188.3DB3EF80
Content-Type: text/html;
	name="ainc-tunis.htm"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="ainc-tunis.htm"

<html>

<head>
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 5.0">
<meta name=3D"ProgId" content=3D"FrontPage.Editor.Document">
<meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dwindows-1252">
<meta http-equiv=3D"Content-Language" content=3D"en-us">
<title>The Arabic Internet Names Consortium AINC</title>
<base target=3D"_blank">
<meta name=3D"Microsoft Theme" content=3D"any-dns 001, default">
<meta name=3D"Microsoft Border" content=3D"none">
</head>

<body background=3D"_themes/any-dns/earth.gif" bgcolor=3D"#FFFFFF" =
text=3D"#000000" link=3D"#0000FF" vlink=3D"#CC0000" =
alink=3D"#00CC00"><!--mstheme--><font face=3D"Times New Roman">

<p align=3D"center"><a href=3D"http://www.arabicdomainname.org">
<img border=3D"0" src=3D"images/ainclogo.gif" width=3D"291" =
height=3D"147"></a></p>
<p align=3D"justify"><b><span style=3D"background-color: =
#FFFF00">&nbsp;&nbsp;&nbsp; The Arabic Internet Names Consortium AINC, =
under the=20
patronage of the Government of Tunisia Ministry of Communications and =
Information Technology, is organizing  AINC=20
fourth General Body Meeting, the Second Arab ccTLD meeting,&nbsp; and =
the Third Arabic=20
Domain Name Seminar titled ( <font face=3D"Arial">
<i>Arabic Domains, eCommerce and Internet - Past, Present and =
Future</i></font><font face=3D"Arial" size=3D"2">) </font>on the=20
15th - 17th of April 2002 at the=20
<a href=3D"http://www.lepalace.com.tn/htmla/sommairea.htm">Le Palace =
Hotel</a>, Tunis, Tunisia.&nbsp; The meetings=20
will discuss arabic domain name registration policies, arabic gTLDs, =
arabic ccTLDs, linguistic concerns,=20
technology=20
IETF direction and other multilingual domain name related =
issues.</span><br>
<br>
<span style=3D"background-color: #FFFF00">&nbsp;&nbsp;&nbsp;
You are cordially invited to attend the meetings which will be open to =
all AINC=20
members and the members of the global domain related agencies ( ICANN, =
IETF, WIPO,=20
ITU, CENTER, Arab League, Arab ICT Forum, ...etc). Final Agenda will be=20
circulated within couple weeks.<br>
</span>
<br>
<span style=3D"background-color: #FFFF00">&nbsp;&nbsp;&nbsp;
I take this opportunity to extend an invitation to you, on behalf of the =

Tunisian Government &amp; Ministry of Communications,&nbsp; to =
participate to this annual=20
regional event, considered one of the top Information Technology and=20
Telecommunications in the region .<br>
</span>
<br>
<span style=3D"background-color: #FFFF00">Please note that =
accommodations and local transportation will be=20
provided by our host, however, we do need your confirmation prior to=20
<font color=3D"#FF0000">March 15,=20
2002</font>.</span><br>
<br>
<span style=3D"background-color: #FFFF00">Best Regards<br>
Asaad Alnajjar&nbsp;
<a href=3D"mailto:[email-masked]?subject=3DAINC Meeting - =
Tunisia">
([email-masked])</a><br>
AINC Executive Director</span><br>
&nbsp;</b></p>
<!--msthemeseparator--><p align=3D"center"><img =
src=3D"_themes/any-dns/fieruled.gif" width=3D"600" height=3D"10"></p>
<form method=3D"POST" action=3D"_derived/nortbots.htm" =
onSubmit=3D"location.href=3D'_derived/nortbots.htm';return false;" =
webbot-onSubmit webbot-action=3D"--WEBBOT-SELF--">
  <!--webbot bot=3D"SaveResults" u-file=3D"_private/ainc-tunis.htm" =
s-format=3D"HTML/PRE" s-label-fields=3D"TRUE" =
b-reverse-chronology=3D"FALSE" s-email-format=3D"TEXT/PRE" =
s-email-address=3D"[email-masked]" b-email-label-fields=3D"TRUE" =
b-email-subject-from-field=3D"TRUE" s-email-subject=3D"Attendance =
Confirmation - Tunisia April 2002" s-date-format=3D"%d %b %Y" =
s-time-format=3D"%H:%M:%S" s-builtin-fields=3D"REMOTE_USER Date Time" =
u-confirmation-url=3D"http://www.arabicdomainname.org" startspan =
--><strong>[FrontPage Save Results Component]</strong><!--webbot =
bot=3D"SaveResults" endspan i-checksum=3D"6561" -->
  <p><strong>Registration form:</strong></p>
  <dl>
    <dd>
    <!--mstheme--></font><table>
      <tr>
        <td><!--mstheme--><font face=3D"Times New Roman"><b><font =
color=3D"#0000FF">Name</font></b><!--mstheme--></font></td>
        <td><!--mstheme--><font face=3D"Times New Roman"><font =
color=3D"#0000FF"><b><input type=3D"text" size=3D"35" maxlength=3D"256" =
name=3D"Username"></b></font><!--mstheme--></font></td>
      </tr>
      <tr>
        <td><!--mstheme--><font face=3D"Times New Roman"><b><font =
color=3D"#0000FF">Company</font></b><!--mstheme--></font></td>
        <td><!--mstheme--><font face=3D"Times New Roman"><font =
color=3D"#0000FF"><b>
        <input type=3D"text" size=3D"35" maxlength=3D"256" =
name=3D"Company"></b></font><!--mstheme--></font></td>
      </tr>
      <tr>
        <td><!--mstheme--><font face=3D"Times New Roman"><b><font =
color=3D"#0000FF">Arrival</font></b><!--mstheme--></font></td>
        <td><!--mstheme--><font face=3D"Times New Roman"><font =
color=3D"#0000FF"><b>
        <input type=3D"text" size=3D"50" maxlength=3D"256" =
name=3D"Arrival"></b></font><!--mstheme--></font></td>
      </tr>
      <tr>
        <td><!--mstheme--><font face=3D"Times New Roman"><b><font =
color=3D"#0000FF">Departure</font></b><!--mstheme--></font></td>
        <td><!--mstheme--><font face=3D"Times New Roman"><font =
color=3D"#0000FF"><b>
        <input type=3D"text" size=3D"50" maxlength=3D"256" =
name=3D"Departure"></b></font><!--mstheme--></font></td>
      </tr>
      <tr>
        <td><!--mstheme--><font face=3D"Times New Roman"><b><font =
color=3D"#0000FF">Other Info</font></b><!--mstheme--></font></td>
        <td><!--mstheme--><font face=3D"Times New Roman"><font =
color=3D"#0000FF"><b>
        <input type=3D"text" size=3D"50" maxlength=3D"256" =
name=3D"Information"></b></font><!--mstheme--></font></td>
      </tr>
      <tr>
        <td><!--mstheme--><font face=3D"Times New Roman"><b><font =
color=3D"#0000FF">E-mail</font></b><!--mstheme--></font></td>
        <td><!--mstheme--><font face=3D"Times New Roman"><font =
color=3D"#0000FF"><b><input type=3D"text" size=3D"35" maxlength=3D"256" =
name=3D"UserEmail"></b></font><!--mstheme--></font></td>
      </tr>
      <tr>
        <td><!--mstheme--><font face=3D"Times New Roman"><b><font =
color=3D"#0000FF">Tel</font></b><!--mstheme--></font></td>
        <td><!--mstheme--><font face=3D"Times New Roman"><font =
color=3D"#0000FF"><b><input type=3D"text" size=3D"35" maxlength=3D"256" =
name=3D"UserTel"></b></font><!--mstheme--></font></td>
      </tr>
      <tr>
        <td><!--mstheme--><font face=3D"Times New Roman"><b><font =
color=3D"#0000FF">FAX</font></b><!--mstheme--></font></td>
        <td><!--mstheme--><font face=3D"Times New Roman"><font =
color=3D"#0000FF"><b><input type=3D"text" size=3D"35" maxlength=3D"256" =
name=3D"UserFAX"></b></font><!--mstheme--></font></td>
      </tr>
    </table><!--mstheme--><font face=3D"Times New Roman">
    </dd>
  </dl>
  <dl>
    <dd>
    <input type=3D"checkbox" name=3D"ContactRequested" =
value=3D"VisaLetterRequested">
    <b>
    <font color=3D"#0000FF">I need an invitation letter for VISA =
application.</font></dd>
    </b>
  <p><strong>Prospective Speakers include your speech Title &amp; brief =
description=20
  below:</strong></p>
  <dl>
    <dd><textarea name=3D"SeminarSpeakers" rows=3D"5" =
cols=3D"50"></textarea></dd>
  </dl>
    <dt>&nbsp;</dt>
  </dl>
  <p><input type=3D"submit" value=3D"Submit Confirmation">
  <input type=3D"reset" value=3D"Clear Form"></p>
</form>
<h5><!--mstheme--><font face=3D"Verdana, Arial, Helvetica" =
color=3D"#0033CC"><font size=3D"1">Asaad Alnajjar&nbsp;
Copyright =A9 2000-2002 [AINC]. All rights reserved.&nbsp;&nbsp;
Revised: <!--webbot bot=3D"TimeStamp" s-type=3D"EDITED" =
s-format=3D"%m/%d/%y" startspan -->03/01/02<!--webbot bot=3D"TimeStamp" =
i-checksum=3D"12482" endspan -->.</font><!--mstheme--></font></h5>

<!--mstheme--></font></body>

</html>
------=_NextPart_000_0011_01C1C188.3DB3EF80--

From: "Liu, Hong" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "'Hollenbeck, Scott'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Pending Update 
Date: Fri, 1 Mar 2002 08:43:10 -0600 
Sender: [email-masked]

Eric,

You raised some good points about the semantics of pending update. We are
well aware of these issues you raised. My approach, at least from what I
learned on this list, is that I'd better state the problem clearly first
before dwelling into solutions, -:)

I take it that you are not objecting to pending update, but want to get the
semantics right regarding whether multiple pending updates should be
serialized on the registrar side. Am I correct?

For those who want to get a quick understanding of this thread, there are
three issues Eric raised in his email. [Eric, please correct me if I
misunderstood your views.]:

(1) Is the registrar allowed to cancel a pending update before it is
confirmed of the execution of the operation?

(2) Is the registrar allowed to issue multiple updates to the same object
before it is confirmed of the execution of the first operation?

(3) What is the mechanism to correlate messages in pending update situation?

To some extent, some of these questions have touched upon the overlapping
areas between registry policy and protocol mechanism. I would like to hear
more discussions from the list.

Please see my comments in line.

--Hong

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Friday, March 01, 2002 4:02 AM
To: Liu, Hong
Cc: 'Eric Brunner-Williams in Portland Maine'; 'Hollenbeck, Scott';
[email-masked]'; [email-masked]
Subject: Re: Pending Update 

>                                                           ... The
registrar
> may not serilize the update operations on an object, i.e., wait for the
> first update to be completed before requesting another. At least we are
not
> making such an assumption.

[snip...]

How does a registrar revoke a hung job (an asychronous write)?  

<HL> 
Whether revocation of a pending update is allowed or not in EPP is an issue
independent of the serialization of update requests from the registrar side.
So we have a decision to make. Then we can talk about possible solutions.
<HL/>

Wouldn't it be simpler to simply do a transport mapping for an existing
filesystem (over tcp) with the semantics you require?

As you observe, data bases do do this (serialize operations against object).

Putting a data base, or at least this bit of semantics, "into" the protocol
is an option. It seems simpler to observe, as Scott did, that asynchronous
exchanges might result in higher error rates if a client issues commands
without waiting to receive the responses for prior commands, rather than to
attempt to guarantee that they won't.

<HL>
Good point. Forcing the serialization of multiple updates on the same object
on the registrar side does simplify the problem, especially on the registry
side. I would like to hear from the registrars what they think of this
issue.
<HL/>

> Do we need more information from EPP, such as time-stamp ...

Scott and Klaus discussed roll-back last September, on-list, and I privately
discussed temporal identifier requirements with Scott on 8 Feb '01.

<HL>
Actually, I was talking about a different problem. Since pending update is
an "extended" transaction, meaning beyond the simple request-response
two-way handshake, we need to have a way to correlate the messages in the
same transaction. The transaction ID can be used for that purpose IF we make
it mandatory in pending update requests. This is another issue we need to
address.
<HL/>

Eric

To: "Liu, Hong" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "'Hollenbeck, Scott'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Pending Update 
Date: Fri, 01 Mar 2002 04:02:06 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>                                                           ... The registrar
> may not serilize the update operations on an object, i.e., wait for the
> first update to be completed before requesting another. At least we are not
> making such an assumption.

Wow. That's novel.

So you want an in-protocol mechanism to ensure the temporally well-ordered
commit of asychronous writes. Because registrars don't view "hung jobs" as
edge-case bugs, subject to registrar-revocation or registry-cancellation,
but as a deferred write, and the effective state of an object the subject
of lazy evaluation semantics.

How does a registrar revoke a hung job (an asychronous write)?  

Wouldn't it be simpler to simply do a transport mapping for an existing
filesystem (over tcp) with the semantics you require?

As you observe, data bases do do this (serialize operations against object).

Putting a data base, or at least this bit of semantics, "into" the protocol
is an option. It seems simpler to observe, as Scott did, that asynchronous
exchanges might result in higher error rates if a client issues commands
without waiting to receive the responses for prior commands, rather than to
attempt to guarantee that they won't.

> Do we need more information from EPP, such as time-stamp ...

Scott and Klaus discussed roll-back last September, on-list, and I privately
discussed temporal identifier requirements with Scott on 8 Feb '01.

Eric