Subject: When 2 == 3
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
To: [email-masked]
Date: Sat, 29 Sep 2001 15:16:34 -0400

All,

I just saw this on the [email-masked] list. It is pretty
funny.

> According to billg's Win32 GetMessage() API, the return value of
> type BOOL can be one of {nonzero|zero|-1} and thus BOOL is tristate.

Eric

To: [email-masked], [email-masked], [email-masked]
cc: [email-masked]
Subject: FYI: P3P Latest republished (editing glitch)
Date: Fri, 28 Sep 2001 15:38:21 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

All,

I'm sending this to the lists where I've mentioned using the P3P vocabulary
as a starting point for discussing policy (privacy and/or data collection)
metadata in some XML marked up transaction stream. This is just so those who
do bother to read some of the spec know that we delta'd the external version
just a few days ago, and to show how facile and adept we are, did it again
three days later (today).

Eric

------- Forwarded Message

Subject: 24 September Last Call Draft republished

Dear all, 

we missed to include a change into the 24 September Last Call
Working Draft. The Draft was therefor republished on 28 September
2001 with the missing changes included. It contains also some
explanatory words in the status-section.

The missing change was:
The P3P Working Group decided a time ago, that an embedded
DATASCHEMA is a child of POLICIES. 

We had to change the date of the document, in case after 3 days,
someone was already relying on it. Nevertheless, the Last Call
period and the namespace etc... remain the same.

The document can be found as usual under 
http://www.w3.org/TR/P3P
or direct under 
http://www.w3.org/TR/2001/WD-P3P-20010928/

------- End of Forwarded Message

Date: Fri, 28 Sep 2001 09:11:24 +0100 (BST)
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: <check> Response Attribute
From: Martin Oldfield <[email-masked]>
Sender: [email-masked]

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:

    Edward> It seems to me that the <check> command would be most
    Edward> useful if it was read as "can I register this name?"  That
    Edward> is primarily a yes/no decision, even if the domain name is
    Edward> out of scope of the registry.  (You can't register a .is
    Edward> name with Verisign's registry.)

Is it worth noting that `Can I register this name ?', is different
from NOT `Is this name registered ?' ?. The former is probably more
useful, but the command seems to do the latter.

Cheers,
-- 
Martin Oldfield,
AdamsNames Ltd.

To: [email-masked]
Subject: FYI: P3P update
Date: Thu, 27 Sep 2001 19:20:34 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

http://www.w3.org/TR/2001/WD-P3P-20010924/
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification
W3C Working Draft 24 September 2001

Updates to the 24 September 2001 Working Draft
http://www.w3.org/P3P/updates.html

(Massimo was editing the the BNF when his host crashed. Upon recover, the
 section in question was broken, and the error not caught until after the
 new Spec (updates 15/12/00 version) was posted. Sigh.
)

Eric
(now taking off my P3P Spec WG hat ...)

Date: Thu, 27 Sep 2001 16:14:58 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: <check> Response Attribute
Sender: [email-masked]

It seems to me that the <check> command would be most useful if it was read
as "can I register this name?"  That is primarily a yes/no decision, even
if the domain name is out of scope of the registry.  (You can't register a
.is name with Verisign's registry.)

As with any yes/no situations, there are times when extra explanation is
helpful.  My question is whether EPP would want to adopt three or four
kinds of responses - yes, no, no with explanation (the three), and possibly
yes with explanation (that being the fourth).

I'm not talking MUST, SHOULD here, I'm asking "what do we need to solve the
problem."

Keep in mind that <check> is the lightweight request/response intended for
limited information.  We discussed this back in February as mostly a
pre-sales function, inherently different from post-sales functions.

As an aside - whether a name exists is a real existentialist dilemma.
Pardon my indulgence here, but in fact all names possible in a zone already
exist - but we haven't thought of them all yet.  DNS names (recognizing
that DNS is just the first topic of registration) are limited to 255
octets, which is about 2K bits, and 2^2k possibilities minus special cases.
Boom - all names exist.  So let's just be concerned about thise we can work
with - those available for registration.  Of course, if someone wants to
debate a different interpretation for the check command, raise it and we'll
look at it.  (I'm not being facetious.)

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

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

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

Date: Thu, 27 Sep 2001 17:32:28 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <check> Response Attribute
Organization: Gandi
Sender: [email-masked]

On Thu, Sep 27, 2001 at 11:24:17AM -0400, Daniel Manley took time to write:
> >In such a case the Registry should return :
> >2307 "Unimplemented object service"
> >This response code MUST be returned when a server receives a command
> >to operate on an object service that is not supported by the server.
> 
> But doesn't that response mean that the <domain:check> command is not 
> implemented? 

No. For that case you have :
2101    "Unimplemented command"
This response code MUST be returned when a server receives a valid
EPP command element that is not implemented by the server.

> I think 2306 "Parameter value policy error" should be returned.

Yes, you are probably right.

> But what if at least one domain in the check domain list was valid.

See explanation of 2306 :
This response code MUST be returned when a server receives a command
containing a parameter value ...
           ^

It matches the case you describe.

I do not find so hard for a client, in such a case, to do its query
again one object by one object to see which one was wrong.
Or to rely on the fact that a <msg> item was given in the 2306 error
code with the exact object that created this error condition.

Patrick.

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: "Paul M. Kane" <[email-masked]>, [email-masked], "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: "opt-in" schema 
Date: Thu, 27 Sep 2001 11:23:46 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

The dan.ca <check> against the .com registry example ...

Distinct namespaces, see also inextant registries, e.g.,

	name.non-iso3166-ccTLD-2LA
or
	name.not-in-icann-g-or-sTLD-set
or
	name.alternate-root-registry-name-same-as-icann-root-registry-name
	(e.g., Ms. Gallagos' .biz in the ARNI root)
or
	name.<null>

Not to flog a dead horse unduly, but as registries can't initiate instances
of communication (absent a pending non-MUST <push> extension), how registry
A could acquire state from registry B is ... undefined.

Earlier, Stuart suggested that the semantics of <check> may be conditional.
He suggested registrant eligibility, but could also have suggested registrar
access. In a non-flat namespace, with sub-registries, registrar access may
be namespace locality dependant. In the NeuLevel proposal to the US DoC, it
was proposed to operate the existing "legacy" locality-based namespace and a
new non-locality-based namespace with distinct policies, and in the locality
portion of the namespace, to possibly restrict registrar access to delegated
2LD and sub-delegated registries.

Thus, an object (name) could "exist" (from the registry's PoV), and the
semantics available to the registrant performing <check> not allow write
access, or possibly even read access.

Eric

Date: Thu, 27 Sep 2001 11:24:17 -0400
From: Daniel Manley <[email-masked]>
To: Patrick <[email-masked]>
CC: [email-masked]
Subject: Re: <check> Response Attribute
Sender: [email-masked]

Patrick wrote:

>On Thu, Sep 27, 2001 at 09:56:26AM -0400, Daniel Manley took time to write:
>
>>With Versign's com/net/org RRP registry, doing a check on "dan.ca" 
>>returns the message "Invalid Attribute Value".  So not only is it 
>>telling me that "dan.ca" is not available, but that the domain name is 
>>invalid.  EPP's <check> command can't do this because the command is 
>>designed in such a way to check more than one object at once and give 
>>+/- flags for each.  The response code reports the overall success of 
>>the command.  I would imagine that most EPP registries would say that a 
>>domain in the wrong TLD is not known to the registry (semantics of "not 
>>known" vs. "not available [from this registry]").
>>
>
>In such a case the Registry should return :
>2307 "Unimplemented object service"
>This response code MUST be returned when a server receives a command
>to operate on an object service that is not supported by the server.
>
>Without any resData of course.
>In the <result>, a <msg> item can tell which object was invalid.
>
>Patrick.
>
But doesn't that response mean that the <domain:check> command is not 
implemented?  I think 2306 "Parameter value policy error" should be 
returned.  But what if at least one domain in the check domain list was 
valid.  The whole command shouldn't fail.

Dan

Date: Thu, 27 Sep 2001 16:45:12 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <check> Response Attribute
Organization: Gandi
Sender: [email-masked]

On Thu, Sep 27, 2001 at 09:56:26AM -0400, Daniel Manley took time to write:
> With Versign's com/net/org RRP registry, doing a check on "dan.ca" 
> returns the message "Invalid Attribute Value".  So not only is it 
> telling me that "dan.ca" is not available, but that the domain name is 
> invalid.  EPP's <check> command can't do this because the command is 
> designed in such a way to check more than one object at once and give 
> +/- flags for each.  The response code reports the overall success of 
> the command.  I would imagine that most EPP registries would say that a 
> domain in the wrong TLD is not known to the registry (semantics of "not 
> known" vs. "not available [from this registry]").

In such a case the Registry should return :
2307 "Unimplemented object service"
This response code MUST be returned when a server receives a command
to operate on an object service that is not supported by the server.

Without any resData of course.
In the <result>, a <msg> item can tell which object was invalid.

Patrick.

To: "Paul M. Kane" <[email-masked]>
cc: [email-masked], "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: "opt-in" schema 
Date: Thu, 27 Sep 2001 09:49:01 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Paul,

Explicit consent to what?

the entity,
data access to the registrant,
the purpose,
the recipients,
the retention period,
etc,

are unspecified. 

Is the "explicit consent" to the request(s) made by resellers, registrars,
and registries, does it attach uniformly to "social" data and to "technical"
data, is it "thick vs thin" registry model independent, and finally, is it
the same "explicit consent" to EPP-external applications, such as whois:43?

Pindar,

I look forward to your example.

Eric

Date: Thu, 27 Sep 2001 09:56:26 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
CC: Eva =?ISO-8859-1?Q?Steng=E5rd?= <[email-masked]>
Subject: Re: <check> Response Attribute
Sender: [email-masked]

Maybe this situation is what's causing a ruckus:

With Versign's com/net/org RRP registry, doing a check on "dan.ca" 
returns the message "Invalid Attribute Value".  So not only is it 
telling me that "dan.ca" is not available, but that the domain name is 
invalid.  EPP's <check> command can't do this because the command is 
designed in such a way to check more than one object at once and give 
+/- flags for each.  The response code reports the overall success of 
the command.  I would imagine that most EPP registries would say that a 
domain in the wrong TLD is not known to the registry (semantics of "not 
known" vs. "not available [from this registry]").

So in gaining the ability to check more than one object, EPP's <check> 
loses the ability to validate a domain name (or rather to report on 
validation of the name).

Yet another alternative:  Perhaps <check> should allow for an "op" like 
transfer.  Values could include "normal" (the default), "extended", 
"validate".  The extended and validate op's could be limited to one 
object per check command to minimize load of the extra work.  Extended 
check would return an additional "reason" attribute for objects known to 
the registry (we've already been over this discussion).  Validating 
checks would verify various things: TLD/SLD permission checks, etc...

Dan

Eva Stengård wrote:

>Hi,
>as I haven't been on this list that long and unfortunatly haven't had time to catch up
>with all the backlog please forgive me if I revisit issues you already have covered
>in length.
>
>Following the discussion it seems to me that the interpretation of the <check>
>command in many cases is "Can I register this object?". Though, reading the
>draft-spec it seems to me that the <check> command just tells me if the object
>exists in the repository or not (="Does this object exist?"). The result can only be 
>yes or no in my opinion. However, this in itself is not enough if my purpose with 
>the <check> have been to determine if I can create a domain object or make a 
>transfer so I can understand the "maybe" suggestions.
>
>Further down I'll list some additional information that I think could be provided 
>in a <msg> element in case of <obj:name> as I believe that a certain number 
>of standard respons messages can be useful even if the need for non-standardised
>messages remains. 
>
>First I'll give you some background. 
>
>I'm writing this from the perspective of a sponsoring organization, in a sense 
>"new kids on the block" but the construct itself already exists for some ccTLDs. 
>Those of you that have been following the ICANN process may have noticed 
>the following from the published parts of the agreements (.museum agreement 
>the only complete so far):
>
>- sponsoring organization is to be separated from registry operator,
>- sponsoring organization is to accredit registrars (minimum number specified),
>- sponsoring organization is responsible for upholding the policies for the domain (i.e. determining if the registrant may register in the TLD and if the proposed domain name conforms to present name rules),
>- Public WHOIS has a new data element "ENS Identity", that's a handle from the sponsoring
>organization, at least in the .museum case,
>- In addition to UDRP a CEDRP, challenges to registrations in violation of charter, 
>is introduced (during which registrar transfers are blocked for all names held by
>challenged registrant). 
>
>As I see it there are several consequences of this for an automated system involving 
>sponsored TLDs (sTLDs), some of which may be subject to separate discussions, 
>such as how to handle a possible three-party dialogue. Though many sTLDs may
>be to small to justify implementation of an automated system such as EPP we should 
>expect some to be large enough.
>
>I'm making a number of assumptions as the basis for my proposals:
>- a registry may operate more than one TLD (including mixtures of ccTLDs and gTLDs),
>- there's not necessarily a strict implementation of "one server - one TLD",
>- a registrar may be accredited to some but not all TLDs the registry operator 
>handles in the system (<check> however is open to all authorized clients),
>- some sponsoring organizations may permit tentative registrations pending
>eligibility verification others may not do so,
>- some (if not all) registries/ sponsoring organizations will require deposits from 
>registrars or impose credit limits,
>- some sponsoring organisations may limit the number of names per registrant,
>- in some TLDs the registrant base may be divided in subgroups that are subject 
>to different naming conventions,
>- client equals to registrar,
>- human errors occur.
>
>If a <check> command looking like the exemple in the draft (epp-04, p.21) is sent the
>response may IMHO include the following one or more <msg> element(s):
>
>"Active"
>"Reserved" [1]
>"Defensive" [2]
>"Pending ENS verification" [3]
>"Pending Name verification" [4] 
>"Pending UDRP resolution"
>"Pending CEDRP resolution"
>"Pending delete"
>"Pending release"
>"Name include reserved label"
>"Name in violation of naming convention" [4]
>
>as the client is known to the server the following information could also 
>be provided if applicable
>
>"Registrar not accredited for TLD"
>"Registrar financial limit reached/exceeded"
>
>If the <check> also includes an ENS identity element more information may 
>be provided such as the following:
>
>"ENS Identity don't exist" [5]
>"ENS Identity not valid" [6]
>"Registrant name limit reached/exceeded"
>"Name in violation of naming convention" [4]
>
>I realize that the listings above are incomplete and will be subject to
>implementation decisions. The first decision is of course if such 
>messages should be included at all in a <check> respons or if all
>such responses should be sent when an transforming action is
>taking place. Those of you operating registries should be able to
>determine the load impact on the server, I can't. At some stage
>the <info> command probably makes better sense to provide 
>further information but can only be used if the initial <check> 
>returned "+" as in "the object exists".
>
>Notes:
>[1] Reservation by ICANN or sponsoring organization.
>[2] Defensive following IP claims or UDRP resolutions etc.
>[3] Only if the sponsor allow tentative registrations of domain names prior to
>elibility clearence.
>[4] In many cases the proposed name itself isn't enough to determine 
>compliance but may be resolved if the ID of the registrant is provided. 
>Sometimes even this will not be enough, hence "Pending name verification".
>A little less specific "Pending verification" for both ENS and name 
>verification is also possible. 
>[5] Human error or registrants trying to pull a fast one may result in this.
>[6] In case the registrant have been challenged through CEDRP and lost the
>right to register in the TLD or have failed to renew/ uphold the right in such 
>cases the sponsor requires periodic eligibility checks.
>
>All this said, it remains to be seen if the museum TLD will ever be part of an 
>EPP environment.
>I hope I'm not to far out on the limb with this.
>
>/Eva
>
>Eva Stengård
>Project Associate
>[email-masked]
>MuseDoma
>The Museum Domain Management Association
>
>Please note that anything expressed here is the personal opinion of the 
>writer and does not in any way represent an official statement or 
>commitment from MuseDoma.
>
>
>
>
>
>
>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Dave Crocker'" <[email-masked]>, Pindar Wong <[email-masked]>
Cc: "'Paul M. Kane'" <[email-masked]>, [email-masked]
Subject: RE: "opt-in" schema
Date: Thu, 27 Sep 2001 07:02:18 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Dave Crocker [mailto:[email-masked]]
>Sent: Thursday, September 27, 2001 1:33 AM
>To: Pindar Wong
>Cc: Hollenbeck, Scott; 'Paul M. Kane'; [email-masked]
>Subject: Re: "opt-in" schema
>
>
>At 05:23 PM 9/26/2001, Pindar Wong wrote:
>>If this group doesn't mind, I'll put together something over this long
>>weekend in Hong Kong, so that we've got something that we can work through
>>to identify the major issues (e.g. atomicity of what is being
>>opted-in-to/out-of).
>
>Pindar, Paul, Scott,
>
>Let me suggest something a little simpler and more general:  A mechanism 
>for exchanging "registry-specific parameters" (RSP), with epp knowing 
>nothing at all about the details of the parameter.

Given the nature of this topic this sounds like an excellent approach.  It
could be doable with the current extension mechanism, which allow a registry
to define whatever parameters it finds appropriate for any particular
operation.

<Scott/>

Date: Wed, 26 Sep 2001 22:33:25 -0700
To: "Pindar Wong" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: "opt-in" schema
Cc: "Hollenbeck, Scott" <[email-masked]>, "'Paul M. Kane'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 05:23 PM 9/26/2001, Pindar Wong wrote:
>If this group doesn't mind, I'll put together something over this long
>weekend in Hong Kong, so that we've got something that we can work through
>to identify the major issues (e.g. atomicity of what is being
>opted-in-to/out-of).

Pindar, Paul, Scott,

Let me suggest something a little simpler and more general:  A mechanism 
for exchanging "registry-specific parameters" (RSP), with epp knowing 
nothing at all about the details of the parameter.

EPP would just pass them reliably and opaquely.  Any meaningful processing 
of the parameters would depend upon the processing entity's obtaining 
knowledge about the semantics from some out-of-band mechanism.

SO the requirement is for a syntactic place to put multiple, arbitrary 
RSPs, between EPP participants.

This way EPP can be used for the part it MUST participate in, but the 
details of semantics, such as the concept of "consent" is left out of EPP's 
sphere of concern.

d/

ps.  Hi, Pindar.

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

Date: Thu, 27 Sep 2001 14:22:29 +1000
From: Adam <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Determining domains associated with a contact.
Sender: [email-masked]

Hi,

Excuse me for probably not using the right referencing for this
question.

In Section 2.2 of the EPP Contact Mapping draft version 0 the specs talk
about status...

linked

The status can include the value 'linked' and 'Servers SHOULD provide
services to determine existing object associations.'

Are there any provisions in the EPP specs to query the server and find
out what domains are associated with a specified contact.  If there are
could someone please point me to them.

Adam.

From: "Pindar Wong" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Paul M. Kane'" <[email-masked]>, <[email-masked]>
Subject: Re: "opt-in" schema
Date: Thu, 27 Sep 2001 08:23:23 +0800
Sender: [email-masked]

If this group doesn't mind, I'll put together something over this long
weekend in Hong Kong, so that we've got something that we can work through
to identify the major issues (e.g. atomicity of what is being
opted-in-to/out-of).

I'll be using an example of using EPP to create a domain name registrant
membership registry that contains the social information identifiers
gathered from the registrars.

Cheers,

p.

----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Paul M. Kane'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 26, 2001 6:57 PM
Subject: RE: "opt-in" schema

> >-----Original Message-----
> >From: Paul M. Kane [mailto:[email-masked]]
> >Sent: Wednesday, September 26, 2001 3:05 AM
> >To: [email-masked]
> >Cc: Hollenbeck, Scott
> >Subject: "opt-in" schema
> >
> >
> >Does the latest version contain parameters for passing from the
> >registrant, via the registrar, to the registry, or other parties,
explicit
> >consent flags?
>
> No, there's nothing defined yet or currently planned for -05 because no
> proposal has been offered that:
>
> - Describes what is being opted-in-to or -out-of.
>
> - Identifies the specific elements that should be subject to opt-*
> considerations.
>
> - Describes how a server should process opt-* requests.
>
> If someone would put together a proposal we would have something to
> consider.
>
> <Scott/>
>

From: "Eva Stengård" <[email-masked]>
To: <[email-masked]>
Subject: RE: <check> Response Attribute
Date: Wed, 26 Sep 2001 22:26:16 +0200
Sender: [email-masked]

Hi,
as I haven't been on this list that long and unfortunatly haven't had time to catch up
with all the backlog please forgive me if I revisit issues you already have covered
in length.

Following the discussion it seems to me that the interpretation of the <check>
command in many cases is "Can I register this object?". Though, reading the
draft-spec it seems to me that the <check> command just tells me if the object
exists in the repository or not (="Does this object exist?"). The result can only be 
yes or no in my opinion. However, this in itself is not enough if my purpose with 
the <check> have been to determine if I can create a domain object or make a 
transfer so I can understand the "maybe" suggestions.

Further down I'll list some additional information that I think could be provided 
in a <msg> element in case of <obj:name> as I believe that a certain number 
of standard respons messages can be useful even if the need for non-standardised
messages remains. 

First I'll give you some background. 

I'm writing this from the perspective of a sponsoring organization, in a sense 
"new kids on the block" but the construct itself already exists for some ccTLDs. 
Those of you that have been following the ICANN process may have noticed 
the following from the published parts of the agreements (.museum agreement 
the only complete so far):

- sponsoring organization is to be separated from registry operator,
- sponsoring organization is to accredit registrars (minimum number specified),
- sponsoring organization is responsible for upholding the policies for the domain (i.e. determining if the registrant may register in the TLD and if the proposed domain name conforms to present name rules),
- Public WHOIS has a new data element "ENS Identity", that's a handle from the sponsoring
organization, at least in the .museum case,
- In addition to UDRP a CEDRP, challenges to registrations in violation of charter, 
is introduced (during which registrar transfers are blocked for all names held by
challenged registrant). 

As I see it there are several consequences of this for an automated system involving 
sponsored TLDs (sTLDs), some of which may be subject to separate discussions, 
such as how to handle a possible three-party dialogue. Though many sTLDs may
be to small to justify implementation of an automated system such as EPP we should 
expect some to be large enough.

I'm making a number of assumptions as the basis for my proposals:
- a registry may operate more than one TLD (including mixtures of ccTLDs and gTLDs),
- there's not necessarily a strict implementation of "one server - one TLD",
- a registrar may be accredited to some but not all TLDs the registry operator 
handles in the system (<check> however is open to all authorized clients),
- some sponsoring organizations may permit tentative registrations pending
eligibility verification others may not do so,
- some (if not all) registries/ sponsoring organizations will require deposits from 
registrars or impose credit limits,
- some sponsoring organisations may limit the number of names per registrant,
- in some TLDs the registrant base may be divided in subgroups that are subject 
to different naming conventions,
- client equals to registrar,
- human errors occur.

If a <check> command looking like the exemple in the draft (epp-04, p.21) is sent the
response may IMHO include the following one or more <msg> element(s):

"Active"
"Reserved" [1]
"Defensive" [2]
"Pending ENS verification" [3]
"Pending Name verification" [4] 
"Pending UDRP resolution"
"Pending CEDRP resolution"
"Pending delete"
"Pending release"
"Name include reserved label"
"Name in violation of naming convention" [4]

as the client is known to the server the following information could also 
be provided if applicable

"Registrar not accredited for TLD"
"Registrar financial limit reached/exceeded"

If the <check> also includes an ENS identity element more information may 
be provided such as the following:

"ENS Identity don't exist" [5]
"ENS Identity not valid" [6]
"Registrant name limit reached/exceeded"
"Name in violation of naming convention" [4]

I realize that the listings above are incomplete and will be subject to
implementation decisions. The first decision is of course if such 
messages should be included at all in a <check> respons or if all
such responses should be sent when an transforming action is
taking place. Those of you operating registries should be able to
determine the load impact on the server, I can't. At some stage
the <info> command probably makes better sense to provide 
further information but can only be used if the initial <check> 
returned "+" as in "the object exists".

Notes:
[1] Reservation by ICANN or sponsoring organization.
[2] Defensive following IP claims or UDRP resolutions etc.
[3] Only if the sponsor allow tentative registrations of domain names prior to
elibility clearence.
[4] In many cases the proposed name itself isn't enough to determine 
compliance but may be resolved if the ID of the registrant is provided. 
Sometimes even this will not be enough, hence "Pending name verification".
A little less specific "Pending verification" for both ENS and name 
verification is also possible. 
[5] Human error or registrants trying to pull a fast one may result in this.
[6] In case the registrant have been challenged through CEDRP and lost the
right to register in the TLD or have failed to renew/ uphold the right in such 
cases the sponsor requires periodic eligibility checks.

All this said, it remains to be seen if the museum TLD will ever be part of an 
EPP environment.
I hope I'm not to far out on the limb with this.

/Eva

Eva Stengård
Project Associate
[email-masked]
MuseDoma
The Museum Domain Management Association

Please note that anything expressed here is the personal opinion of the 
writer and does not in any way represent an official statement or 
commitment from MuseDoma.

To: Edward Lewis <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: <check> Response Attribute 
Date: Wed, 26 Sep 2001 14:24:55 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Opps.

> regardless of the operands, could a registry detect which algorithm

s/registry/registrar/

Eric

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: <check> Response Attribute 
Date: Wed, 26 Sep 2001 14:02:48 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

What does "exist" and "not exist" actually mean in this context?

If the registry used a good [1] random number generator and modulo 2
arithmatic to generate the {0,1} return value of a boolean <check>,
or always returned the value {0}, or always returned the value {1},
regardless of the operands, could a registry detect which algorithm
{random, always false, always true} was used?

I probably misunderstand what registrars do, and why, but if <check>
discloses some externally visible state(s), how is it externalized
from the registry, and how is it visible? Alternatively, is <check>
simply a means of expressing a protocol-visible consequence of the
application of a query or particularly a transform command upon an
object?

Next, what datatype is appropriate for the "reason why" portion of the
new <check> return?

Eric

[1] http://search.ietf.org/internet-drafts/draft-eastlake-randomness2-02.txt

To: Bruce Tonkin <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: ".au" registry technical specification 
Date: Wed, 26 Sep 2001 09:29:13 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Bruce,

> Note section 2.2, where a new registry/registrar protocol is proposed on the
> basis that
>	the barriers are too high for registrars to use EPP,

2.2 General guidence on barriers to entry, I didn't find the specific
reference to EPP. The same general guidence should be offered to the
registry operator, see also 2.2 item (a). A "competitive" requirement
(a mechanism to meet the theoretical technical requirements of a pool
of registrars, e.g., the 70+ ICANN registrars) may be sufficient to be
a barrier to entry for a proposed registry operator. The technical bar
to entry (and of negative utility where registrant scale is << 10^^5)
is independent of the business issues posed by "competitive" requirements,
which may also be sufficient to be a barrier to entry for a proposed
registry operator.

It is hard to imagine a registry with 10^^3 registrants adopting EPP.
It becomes possible to imagine when the registrant volume is 10^^4.

My assumption is that the .biz registry will have an registrant volume
of 10^^6 -- scale-equivalence with the RRP registries.

Various proposals have been commented upon in this list as having the same
general undesirable characteristic mentioned in this general guidance para,
of being awkward for ICANN registrars, or undesirably complex. A personal
list is transport other than TLS/TCP, asynchronous processing, inheritance
derivations as metaobjects, and metadata. This list is non-exhaustive.

Nominally, some of these proposals could lower the point at which transition
to EPP is economically and technically feasible. Other conceivable proposals,
e.g., transport over SMTP, would lower the transition point.

I'm glad to see that AUNIC and Nominet use SMTP as transport. That was were
we (Crocker, Wesson, Gaetano, Brunner, et al) started at the Orlando IETF BoF
on an SRS -- that SMTP was manditory to implement, if the protocol was to be
of IAHC-general, not ICANN-gTLD, utility.

The consequence of forming a collaborative party restricted to persons or
entities with current or current-year RRP scale-equivalence holdings and/or
expectations, is that the "industry standard" product narrowly reflects the
interests of its creators.

Broadly, the question could be does EPP scale, down not up, from the sweet
spot of RRP scale-equivalence, for registries, and for registrars?

>	and there are no open implementations of EPP available.

2.2 item (e).

An interesting issue. EPP RTKs are available, there is the .info one in java,
the .name one in C++, ours, and possibly others. These contain an EPP client,
in various implementation specific forms (*nix, Win, C++, java), but not the
EPP server, a data base or data base interface, a whois server, and any other
bits that comprise a registry.

My take on the way this issue is posed in the report is that until there is
a server (grotty dbms or dbms interface bits included) implementation that
is "public domain" (or open or reasonably licensed), this issue isn't solved
as far as the Competition Panel (George Michaelson ???) is concerned.

> If it is too hard to implement the IETF standard there will be little take
> up outside a few gtlds.

I agree, and don't view solving contract problems, or competitive problems,
as being a reason for the IETF to form a working group.

Milage varies.

Eric

To: Mike Lampson <[email-masked]>
cc: "'ietf-provregcafaxse'" <[email-masked]>, Daniel Manley <[email-masked]>
Subject: Re: <check> Response Attribute 
Date: Wed, 26 Sep 2001 13:51:01 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    Maybe it's too late for this, but what us Registrars need to know is whether
    the name is available for registration, not if it exists.  If a name cannot
    be registered, I don't really care if it can't be registered because it
    already exists or because it is reserved.

Some registries have a policy were one can actually request that
the a special status such as resereved, blockes, etc.  can be
dropped. At the .nl rgistry we have/had various different reasons
why names cannot/could not be registered. If you try, you'll get
a response in the style of ``reserved according to rule x.y of the
regulations''. Depending on which rule is citated, one can sometime
follow a procedure to get the name afterall.

Other registries might have similar policies. So, depending on the
registry, the registrar might actually want to know.

	jaap

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Paul M. Kane'" <[email-masked]>, [email-masked]
Subject: RE: "opt-in" schema
Date: Wed, 26 Sep 2001 06:57:38 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Paul M. Kane [mailto:[email-masked]]
>Sent: Wednesday, September 26, 2001 3:05 AM
>To: [email-masked]
>Cc: Hollenbeck, Scott
>Subject: "opt-in" schema
>
>
>Does the latest version contain parameters for passing from the
>registrant, via the registrar, to the registry, or other parties, explicit
>consent flags?

No, there's nothing defined yet or currently planned for -05 because no
proposal has been offered that:

- Describes what is being opted-in-to or -out-of.

- Identifies the specific elements that should be subject to opt-*
considerations.

- Describes how a server should process opt-* requests.

If someone would put together a proposal we would have something to
consider.

<Scott/>

Date: Wed, 26 Sep 2001 12:07:43 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <check> Response Attribute
Organization: Gandi
Sender: [email-masked]

On Tue, Sep 25, 2001 at 04:28:14PM -0400, Jordyn A. Buchanan took time to write:
> At 10:30 AM -0400 9/25/01, Edward Lewis wrote:
> >The rational behind #1 is that either a name is or is not available.
> >Although future extentions are always a consideration, extending the
> ><check> command is of questionable value.
> 
> Not to make things too complicated, but what about when the status of 
> a name is unknown (for example, if someone built an EPP frontend to a 
> less automated system).  Is this sort of scenario worth recognizing 
> in the protocol design?

In that case I think this EPP server does not support at all the
Check command, whose purpose is to check the availability.
If the EPP server is not able to process Check commands, it should
reply back with an error code of 2101 ``Unimplemented command''
in my POV.

Patrick.

Date: 26 Sep 2001 09:21:03 -0000
From: [email-masked]
To: [email-masked]
Subject: Re: Length of Reason String
Sender: [email-masked]

I agree,

but back to the length of the "reason string". The longest current status enum
is 24 characters, so that must be the bare minimum, in my view.

Asbjorn

On Tue, 25 Sep 2001 23:17:35 -0400 Daniel Manley <[email-masked]> wrote:
>I'm thinking that DoS attacks shouldn't be much of a concern in EPP 
>since registrar authentication is required.  At least in the world of 
>domain name registrations, ICANN would certainly have something to say 
>to registrars that attempt DoS attacks on registries.
>
>But in non-domain domains, things might be a little different.
>
>Dan
>
>Hollenbeck, Scott wrote:
>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]]
>>>Sent: Tuesday, September 25, 2001 9:59 PM
>>>To: [email-masked]
>>>Subject: RE: Length of Reason String
>>>
>>>
>>>On 25 Sep 01, at 20:16, Hollenbeck, Scott wrote:
>>>
>>>>I don't see the relation to sloppy coding or DoS attacks.
>>>>
>>>Hi Scott,
>>>I don't mean to say that we shouldn't use strings.
>>>And of course we should limit the length.
>>>(or shouldn't we?)
>>>
>>>It's just sloppy coding in the implementation can results in
>>>DoS attack (depends on the implementation of course).
>>>For example if we limit the length of reason string to 16 chars.
>>>Then, I create a nasty server which sends 10.000 chars, eg
>>>
>>>- this-is-a-very-long-rely-beyond-32-characters-and-i-am-going-to-see-
>>>which-implementation-crashes-or-give-me-access-to-their-workstation-
>>>wha-ha-haAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
>>>
>>
>>Actually, these sorts of long strings will/should get caught and flagged as
>>errors by the XML parser before they get too far.  Buffer overflow might be
>>a problem with a buggy parser, so I see what you're saying.  It's a risk
>>with strings.
>>
>><Scott/>
>>
>
>
>
>

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

Date: Wed, 26 Sep 2001 08:05:08 +0100
From: "Paul M. Kane" <[email-masked]>
Organization: REACTO.com
To: [email-masked]
CC: "Hollenbeck, Scott" <[email-masked]>
Subject: "opt-in" schema
Sender: [email-masked]

I have not been following recent discussions, so apologies if this has
already been addressed....

Does the latest version contain parameters for passing from the
registrant, via the registrar, to the registry, or other parties, explicit
consent flags?

The reason is that "explicit consent" is likely to become increasingly
important.  In the WHOIS world - rights to publish data, in the ICANN
world - request to join the AtLarge membership, with regard to applicable
use (sorry terrible term!) as to eligibility/membership/associations, and
in light of the horrific events of Sept 11, the registrar (and Registry)
community may (in the future) be subject to specific undertakings (under
law) and need legal safeguards by offering explicit "opt-in" (or opt-out)
provision to limit the scope of their liability.

Best regards

Paul

Date: Tue, 25 Sep 2001 23:17:35 -0400
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Length of Reason String
Sender: [email-masked]

I'm thinking that DoS attacks shouldn't be much of a concern in EPP 
since registrar authentication is required.  At least in the world of 
domain name registrations, ICANN would certainly have something to say 
to registrars that attempt DoS attacks on registries.

But in non-domain domains, things might be a little different.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]
>>Sent: Tuesday, September 25, 2001 9:59 PM
>>To: [email-masked]
>>Subject: RE: Length of Reason String
>>
>>
>>On 25 Sep 01, at 20:16, Hollenbeck, Scott wrote:
>>
>>>I don't see the relation to sloppy coding or DoS attacks.
>>>
>>Hi Scott,
>>I don't mean to say that we shouldn't use strings.
>>And of course we should limit the length.
>>(or shouldn't we?)
>>
>>It's just sloppy coding in the implementation can results in
>>DoS attack (depends on the implementation of course).
>>For example if we limit the length of reason string to 16 chars.
>>Then, I create a nasty server which sends 10.000 chars, eg
>>
>>- this-is-a-very-long-rely-beyond-32-characters-and-i-am-going-to-see-
>>which-implementation-crashes-or-give-me-access-to-their-workstation-
>>wha-ha-haAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
>>
>
>Actually, these sorts of long strings will/should get caught and flagged as
>errors by the XML parser before they get too far.  Buffer overflow might be
>a problem with a buggy parser, so I see what you're saying.  It's a risk
>with strings.
>
><Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jordyn A. Buchanan'" <[email-masked]>
Cc: [email-masked]
Subject: RE: <check> Response Attribute
Date: Tue, 25 Sep 2001 21:45:56 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2001 5:36 PM
> To: Rick H Wesson
> Cc: Edward Lewis; [email-masked]
> Subject: RE: <check> Response Attribute
> 
> 
> At 2:24 PM -0700 9/25/01, Rick H Wesson wrote:
> >Jordyn,
> >
> >If the name is available then yes is the only answer, if the 
> domains is
> >not available or MAYBE availabe then no is the appropiate answer.
> 
> Hmm?  From a registrar perspective, if the registry says a name is 
> *not* available, then I am not going to try to register a name.  If 
> it might be available or might not be, I would probably try.  "Maybe" 
> seems closer to "available" than "not available" in my mind.

I don't see how a registry can be undecided about object availability.  At
any given moment in time, an object is either available or it isn't.  It
might be available with conditions, but it's available, and the purpose of
the <check> isn't to explain the preconditions that might have to be met for
a <create> to be accepted.  It's supposed to be a light-weight, fast
operation that helps a client decide if a <create> might or might not work.

> I'm open to suggestions that we could supplement the "available" or 
> "not available" responses with codes to indicate uncertainty, but it 
> seems like an indeterminate state is a possible one that we should 
> get a grip on before deciding that <check> is only going to boolean.
>
> Ed R. raised the point of asynchrony, which I alluded to earlier. 
> What if the EPP implementation is just a frontend to a non-realtime 
> process?  Is it desirable to try and accomodate such a situation?  I 
> think probably yes, which means we need to be able to deal with 
> indeterminate responses.

I think the whole idea of indeterminate responses is BAD for both client and
server.  It implies client and server state management responsibilities for
the duration of pending transactions, adding a layer of complexity of
questionable utility.  Things are far simpler to implement and manage given
real-time interactions with unambiguous responses, even if some of the
responses ultimately mean something akin to the "pendingVerification" domain
status.

BTW, we have covered this topic before.  See section 3.6 of the requirements
draft.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Length of Reason String
Date: Tue, 25 Sep 2001 21:35:44 -0400
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2001 9:59 PM
> To: [email-masked]
> Subject: RE: Length of Reason String
> 
> 
> On 25 Sep 01, at 20:16, Hollenbeck, Scott wrote:
> 
> > I don't see the relation to sloppy coding or DoS attacks.
> 
> Hi Scott,
> I don't mean to say that we shouldn't use strings.
> And of course we should limit the length.
> (or shouldn't we?)
> 
> It's just sloppy coding in the implementation can results in
> DoS attack (depends on the implementation of course).
> For example if we limit the length of reason string to 16 chars.
> Then, I create a nasty server which sends 10.000 chars, eg
> 
> - this-is-a-very-long-rely-beyond-32-characters-and-i-am-going-to-see-
> which-implementation-crashes-or-give-me-access-to-their-workstation-
> wha-ha-haAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...

Actually, these sorts of long strings will/should get caught and flagged as
errors by the XML parser before they get too far.  Buffer overflow might be
a problem with a buggy parser, so I see what you're saying.  It's a risk
with strings.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: <check> Response Attribute
Date: Tue, 25 Sep 2001 21:20:04 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Ed Rahn [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2001 5:28 PM
> To: Edward Lewis
> Cc: Jordyn A. Buchanan; [email-masked]; [email-masked]
> Subject: RE: <check> Response Attribute
> 
> 
> How would a <create> command deal with an object that returned a <check>
> of "maybe". It would either need to create the object, or not create it.

Exactly.  At any given point in time an object is either available, or it
isn't.  The <check> is supposed to be nothing more than a fast, light-weight
hint that helps a client decide if a <create> could work.  <create> then
returns an unambiguous success or failure response, not something like
"might have been created".

> Addressing Jordyn's comments. Could EPP be used in some type of
> asynchronous fashion? I searched through the "Generic Registry-Registrar
> Protocol Requirements" draft quickly and did not see anything concerning
> realtime or delayed actions. If EPP could be used in a delayed environment
> a "maybe" responce might be needed. In this case "yes" would be not be
> used, and we would still be using a two responce system.

Think email transport as one option, and yes, EPP can be used that way.  I
don't see how a "maybe" comes up even here, though, because at the moment in
time that the command gets executed there shouldn't be any ambiguity.  That
may change before a <create> is attempted, but that situation exists even in
a real-time environment.  That's why <check> is a _hint_, and not a
guarantee of success or failure.

> Addressing Edward's comments. Would we want to make <check>
> conditional? This could not only be necessary for domains but any other
> object that would require some type of prerequesits, such as secure
> certificates. I'm under the opinion that  a <check> would return a
> "no" and then set some type of reason, an <info> command could be used to
> obtain the necessary prerequesits.

No, I don't think it makes sense to make <check> conditional.  It's utility
comes in providing a fast, unambiguous pre-<create> hint.  <info> is
designed to return information for a single registered object, not general
server-specific policy information that is better documented outside the
protocol.

We already have a provision in the domain mapping document to deal with a
situation where offline processing is needed to completely confirm object
creation.  The <create> returns an unambiguous response, and (if needed) the
status of the object gets initially set to "pendingVerification".  After the
offline verification process is completed, the object either gets set to
"active", or maybe the server deletes the object and sends the client a
notice, or it does whatever it needs to do, but there's never any doubt
about the success or failure of any particular command.

<Scott/>

From: [email-masked]
To: [email-masked]
Date: Wed, 26 Sep 2001 08:58:36 +0700
Subject: RE: Length of Reason String
Sender: [email-masked]

On 25 Sep 01, at 20:16, Hollenbeck, Scott wrote:

> I don't see the relation to sloppy coding or DoS attacks.

Hi Scott,
I don't mean to say that we shouldn't use strings.
And of course we should limit the length.
(or shouldn't we?)

It's just sloppy coding in the implementation can results in
DoS attack (depends on the implementation of course).
For example if we limit the length of reason string to 16 chars.
Then, I create a nasty server which sends 10.000 chars, eg

- this-is-a-very-long-rely-beyond-32-characters-and-i-am-going-to-see-
which-implementation-crashes-or-give-me-access-to-their-workstation-
wha-ha-haAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...

or
- the-reason-this-domain-is-not-available-is-because-of-we-say-so-and-
there-is-nothing-you-can-do-about-it

or

+ this-domain-is-available-but-pay-me-100-bucks-and-show-me-the-money-
first.
(like the ones used in many attacks)

But that's the implementation side. Nothing[?]/little[?]
to do with the spec. It's just that I've seen too many
things of this. Gives me the chillies... (or warmth? ;-)

-- budi

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: Length of Reason String
Date: Tue, 25 Sep 2001 20:16:36 -0400
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2001 8:39 PM
> To: [email-masked]
> Subject: Length of Reason String
> 
> 
> Character strings always remind me of sloppy coding, DoS attack.
> Then there's also internationalization issue. :-(

I don't see the relation to sloppy coding or DoS attacks.  We have built-in
UTF-8 support and language tags that we can use to deal with
internationalization issues.

<Scott/>

From: [email-masked]
To: [email-masked]
Date: Wed, 26 Sep 2001 07:39:13 +0700
Subject: Length of Reason String
Sender: [email-masked]

On 25 Sep 01, at 13:29, Hollenbeck, Scott wrote:

> Given this guidance, it appears that we should further explore the "reason
> as string" option that's been discussed.  I believe it appropriate to define
> an upper limit on the length, but what do folks think is sufficient?  16
> characters?  24 characters?  Something else?

What's the length's upper limit of FTP, STMP return string?
eg.:
ftp> dir
...
226 Transfer complete.

telnet localhost 25
220 bhtv-email-server ESMTP gruwo-mailer
HELO localhost
250 have we met before?

Maybe we can learn something from them? I don't have any
reference handy at this moment.

BTW,
Character strings always remind me of sloppy coding, DoS attack.
Then there's also internationalization issue. :-(

-- budi

Date: Tue, 25 Sep 2001 17:36:19 -0400
To: Rick H Wesson <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: <check> Response Attribute
Cc: Edward Lewis <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 2:24 PM -0700 9/25/01, Rick H Wesson wrote:
>Jordyn,
>
>If the name is available then yes is the only answer, if the domains is
>not available or MAYBE availabe then no is the appropiate answer.

Hmm?  From a registrar perspective, if the registry says a name is 
*not* available, then I am not going to try to register a name.  If 
it might be available or might not be, I would probably try.  "Maybe" 
seems closer to "available" than "not available" in my mind.

I'm open to suggestions that we could supplement the "available" or 
"not available" responses with codes to indicate uncertainty, but it 
seems like an indeterminate state is a possible one that we should 
get a grip on before deciding that <check> is only going to boolean.

Ed R. raised the point of asynchrony, which I alluded to earlier. 
What if the EPP implementation is just a frontend to a non-realtime 
process?  Is it desirable to try and accomodate such a situation?  I 
think probably yes, which means we need to be able to deal with 
indeterminate responses.

Jordyn

Date: Tue, 25 Sep 2001 16:27:51 -0500 (CDT)
From: Ed Rahn <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: "Jordyn A. Buchanan" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: <check> Response Attribute
Sender: [email-masked]

How would a <create> command deal with an object that returned a <check>
of "maybe". It would either need to create the object, or not create it.

Addressing Jordyn's comments. Could EPP be used in some type of
asynchronous fashion? I searched through the "Generic Registry-Registrar
Protocol Requirements" draft quickly and did not see anything concerning
realtime or delayed actions. If EPP could be used in a delayed environment
a "maybe" responce might be needed. In this case "yes" would be not be
used, and we would still be using a two responce system.

Addressing Edward's comments. Would we want to make <check>
conditional? This could not only be necessary for domains but any other
object that would require some type of prerequesits, such as secure
certificates. I'm under the opinion that  a <check> would return a
"no" and then set some type of reason, an <info> command could be used to
obtain the necessary prerequesits.

Ed Rahn
ItsYourDomain.com

On Tue, 25 Sep 2001, Edward Lewis wrote:

> At 4:28 PM -0400 9/25/01, Jordyn A. Buchanan wrote:
> >I agree with the approach outlined by Ed in general, but some thought
> >should go into whether or not "Maybe" should be an answer along with
> >"Yes" and "No.
> 
> I say this with two things in mind:
> 1) Don't let a chair decision be the reason for a mistake.
> 2) As I don't do day-to-day registration activities, I try to remain a referee.
> 
> What is the difference between "maybe" and "yes" with a qualifying
> statement (recognizing that there is an impact to an implemetation)?  Or,
> perhaps, "no" with a qualifier?  (E.g., the name is available for a cost of
> 10.000 Euros, but not for less.)
> 
> Is there an example of a registration process that uses "maybe" as a return
> for a check command today, or a process that has "maybe" in its design?
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                NAI Labs
> Phone: +1 443-259-2352                      Email: [email-masked]
> 
> You fly too often when ... the airport taxi is on speed-dial.
> 
> Opinions expressed are property of my evil twin, not my employer.
> 
> 
> 

Date: Tue, 25 Sep 2001 14:24:51 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: "Jordyn A. Buchanan" <[email-masked]>
cc: Edward Lewis <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: <check> Response Attribute
Sender: [email-masked]

Jordyn,

If the name is available then yes is the only answer, if the domains is
not available or MAYBE availabe then no is the appropiate answer.

-rick

On Tue, 25 Sep 2001, Jordyn A. Buchanan wrote:

> At 10:30 AM -0400 9/25/01, Edward Lewis wrote:
> >The rational behind #1 is that either a name is or is not available.
> >Although future extentions are always a consideration, extending the
> ><check> command is of questionable value.
>
> Not to make things too complicated, but what about when the status of
> a name is unknown (for example, if someone built an EPP frontend to a
> less automated system).  Is this sort of scenario worth recognizing
> in the protocol design?
>
> I agree with the approach outlined by Ed in general, but some thought
> should go into whether or not "Maybe" should be an answer along with
> "Yes" and "No.
>
> Jordyn
>

Date: Tue, 25 Sep 2001 16:41:45 -0400
To: "Jordyn A. Buchanan" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: <check> Response Attribute
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 4:28 PM -0400 9/25/01, Jordyn A. Buchanan wrote:
>I agree with the approach outlined by Ed in general, but some thought
>should go into whether or not "Maybe" should be an answer along with
>"Yes" and "No.

I say this with two things in mind:
1) Don't let a chair decision be the reason for a mistake.
2) As I don't do day-to-day registration activities, I try to remain a referee.

What is the difference between "maybe" and "yes" with a qualifying
statement (recognizing that there is an impact to an implemetation)?  Or,
perhaps, "no" with a qualifier?  (E.g., the name is available for a cost of
10.000 Euros, but not for less.)

Is there an example of a registration process that uses "maybe" as a return
for a check command today, or a process that has "maybe" in its design?

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

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

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

Date: Tue, 25 Sep 2001 16:28:14 -0400
To: Edward Lewis <[email-masked]>, [email-masked]
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: <check> Response Attribute
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 10:30 AM -0400 9/25/01, Edward Lewis wrote:
>The rational behind #1 is that either a name is or is not available.
>Although future extentions are always a consideration, extending the
><check> command is of questionable value.

Not to make things too complicated, but what about when the status of 
a name is unknown (for example, if someone built an EPP frontend to a 
less automated system).  Is this sort of scenario worth recognizing 
in the protocol design?

I agree with the approach outlined by Ed in general, but some thought 
should go into whether or not "Maybe" should be an answer along with 
"Yes" and "No.

Jordyn

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: <check> Reason String
Date: Tue, 25 Sep 2001 13:29:36 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Edward Lewis [mailto:[email-masked]]
>Sent: Tuesday, September 25, 2001 10:30 AM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: RE: <check> Response Attribute
>
>
>The reasoning behind #2 is that policy varies from registry to registry,
>and EPP is to be policy neutral.  IMHO, it is too early to try to make an
>all inclusive enumeration of all reasons for "no" so we shouldn't waste
>time trying to do so now.  Note - the means of return a "why" need to be
>defined in an internationalized manner.  This is something I didn't see
>explicitly suggested in any message.

Given this guidance, it appears that we should further explore the "reason
as string" option that's been discussed.  I believe it appropriate to define
an upper limit on the length, but what do folks think is sufficient?  16
characters?  24 characters?  Something else?

<Scott/>

Date: Tue, 25 Sep 2001 10:30:03 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: RE: <check> Response Attribute
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Wow, another contentious debate over a fairly small feature.  Imagine that,
in the IETF!  (Yes, a bit of sarcasm, folks.)

After reading the thread and other considerations, it seems that there is
consensus that, and good technical reason to state that:

1) The result of a <check> is a boolean value.
2) A <check> should also be able to return a reason why (if applicable) a
name is unavailable.

The rational behind #1 is that either a name is or is not available.
Although future extentions are always a consideration, extending the
<check> command is of questionable value.

The reasoning behind #2 is that policy varies from registry to registry,
and EPP is to be policy neutral.  IMHO, it is too early to try to make an
all inclusive enumeration of all reasons for "no" so we shouldn't waste
time trying to do so now.  Note - the means of return a "why" need to be
defined in an internationalized manner.  This is something I didn't see
explicitly suggested in any message.

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

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

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: [email-masked]
Subject: RE: <check> Response Attribute 
Date: Mon, 24 Sep 2001 20:13:18 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 2:47 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: <check> Response Attribute 
> 
> 
> So now the text is controlling, not the schema?

I'm not sure how you inferred the above from my last message, which cited
the current schema.  Just to be clear, I'll repeat what I said last Friday
[1] and what I meant in my last message [2]:

The schema is the formal specification.

Section 4.2 of epp-04 (the shared structure schema) enumerates two possible
values for the "x" attribute: "+" and "-".  The text in section 2.9.2.1
reads as follows:

... "and contain an "x" attribute whose value identifies the object as
either "+" for a known object or "-" for an unknown object."

I do not see any inconsistency between the schema and the text in terms of
describing the two valid values.  If your contention is that the meaning of
the two values is described in the text, and not the schema, you're quite
correct -- that's a limitation of the current schema, and that's exactly why
I think both schema and text need to be changed.

This thread started with a suggestion to replace what I initially wrote as a
kludge to provide a binary yes/no response in as few characters as possible
with a standard XML Schema method of expressing binary alternatives.  The
original suggestion has been met with both disagreement and agreement with
an amendment (amendment: add an additional attribute to describe reasons for
unavailability).  I didn't think this would be such a contentious issue, but
given the debate I'd like to ask for chair guidance before either keeping
things as-is or making any changes.

<Scott/>

[1] http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00099.html

[2] http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00120.html

To: Ed Rahn <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: <check> Response Attribute 
Date: Mon, 24 Sep 2001 17:49:27 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

The current datetype in the schema is "token".

What, and how many values, are currently tossed about is not the same issue
as changing that datatype to boolean.

The current description in the text is not "token".

One of these is normative, if they are not identical.

Dualism has its adherents, but it is possible that more than two distinct
non-degerate states can exist, independent of the rationals associated to
them (the "whys").

Your observation that The Theory of Error Codes is dated is noted.

Eric

Date: Mon, 24 Sep 2001 16:29:10 -0500 (CDT)
From: Ed Rahn <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: <check> Response Attribute 
Sender: [email-masked]

Eric, 

On Mon, 24 Sep 2001, Eric Brunner-Williams in Portland Maine wrote:

> >> 1. Discussion of types.
> ...
> > I'm am under the opinion that this should be changed to a boolean type to
> > better represent what the check command is really suppose to do, and has
> > been documented to do.
> 
> You wrote to the same effect earlier today. I suppose that it is a nuance
> whether the schema is controlling, or the descriptive text, but I prefer
> the former, which as far as I'm concerned, is correct as to type, and as
> to mechanism to represent object state when <check> is the operand, and is
> extensible.
> 
> >> 2. Discussion of registry state.
> ...
> > Registrar specific information should not be in the standards draft.
> 
> The discussion is of registry state, or at least its external (protocol)
> representation.
> 
> >                                                                      That
> > would not be fesable, and is the reason another attribute should be
> > created, or possibly returning a value in the <msg> field as to why it is
> > not available. 
> 
> Assuming you wrote "registrar" when you ment "registry", would you be
> specific please?
> 

My fault, I did mean registry.

It had been suggested that instead of changing the x attribute of the
check responce to a boolean type, that this be extended to not only return
if the domain is available or not, but why it is not available. If instead
of returning available or not the server returned why, the client would
need to know about all possible responces, and all of the responces would
need to be documented. As more registry's adopt EPP, it will become more
and more difficult to update the documentation to reflect all the possible
return values.

Because of this the reason why the domain is not available or even why
it is, whould be stored in another field. 

> >> 3. Extensibility within type and of state.
> ...
> > Creating another attribute on the check responce would allow for responces
> > limited to the length of the field * the number of characters in the
> > applicable character set.
> 
> This appears to follow from your second point, above. 
> 
> If you haven't read rfc640 recently, I commend it to your attention.
> 

This could be another way to a return <check> responce, however I believe
that this way of thinking of things is a bit out dated. The same results
could be achieved from a boolean x attribute, and a text attribute
describing the reason x was given such a value.

> Eric
> 

Ed Rahn
itsyourdomain.com

To: Ed Rahn <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: <check> Response Attribute 
Date: Mon, 24 Sep 2001 16:53:19 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>> 1. Discussion of types.
...
> I'm am under the opinion that this should be changed to a boolean type to
> better represent what the check command is really suppose to do, and has
> been documented to do.

You wrote to the same effect earlier today. I suppose that it is a nuance
whether the schema is controlling, or the descriptive text, but I prefer
the former, which as far as I'm concerned, is correct as to type, and as
to mechanism to represent object state when <check> is the operand, and is
extensible.

>> 2. Discussion of registry state.
...
> Registrar specific information should not be in the standards draft.

The discussion is of registry state, or at least its external (protocol)
representation.

>                                                                      That
> would not be fesable, and is the reason another attribute should be
> created, or possibly returning a value in the <msg> field as to why it is
> not available. 

Assuming you wrote "registrar" when you ment "registry", would you be
specific please?

>> 3. Extensibility within type and of state.
...
> Creating another attribute on the check responce would allow for responces
> limited to the length of the field * the number of characters in the
> applicable character set.

This appears to follow from your second point, above. 

If you haven't read rfc640 recently, I commend it to your attention.

Eric

Date: Mon, 24 Sep 2001 15:26:12 -0500 (CDT)
From: Ed Rahn <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: <check> Response Attribute
Sender: [email-masked]

On Mon, 24 Sep 2001, Eric Brunner-Williams in Portland Maine wrote:

> The proposal of 9/21 by the editor of draft-provreg-epp, to make a specific
> modification of a schema, is discussed.
> 
> There are three related issues. One is the data type returned by an operator.
> Another is registry state for the operator's (object) operands. A third is
> the extensibility of the first and second.
> 
> 1. Discussion of types.
> 
> The present schema, from draft-ietf-provreg-epp-04.txt (line numbers added),
> is:
> 
>    2954   <!--
>    2955   <check> result type.
>    2956   -->
>    2957     <simpleType name="checkType">
>    2958       <restriction base="token">
>    2959         <enumeration value="+"/>
>    2960         <enumeration value="-"/>
>    2961       </restriction>
>    2962     </simpleType>
>  
> The base type for "token" [t] is "normalizedString" [n], which in turn has
> a base type of "string" [s], a primitive datatype. "boolean" [b] is also a
> primitive datatype.
> 
> Definitional texts:
> 
> [Definition:] token represents tokenized strings. The value space of token
> is the set of strings that do not contain the line feed (#xA) nor tab (#x9)
> characters, that have no leading or trailing spaces (#x20) and that have no
> internal sequences of two or more spaces. The lexical space of token is the
> set of strings that do not contain the line feed (#xA) nor tab (#x9)
> characters, that have no leading or trailing spaces (#x20) and that have no
> internal sequences of two or more spaces.
> 
> [Definition:]  boolean has the value space required to support
> the mathematical concept of binary-valued logic: {true, false}. 
> 
> Considered as a question of types, the proposal is to change the tuple used,
> the primitive datatype, restricting the value space to the {true,false,1,0}
> set, restricting the lexical space, and restricting the set of facets, from
> those of "token" to those of "boolean".
> 
> [t] http://www.w3.org/TR/xmlschema-2/#token
> [n] http://www.w3.org/TR/xmlschema-2/#normalizedString
> [s] http://www.w3.org/TR/xmlschema-2/#string
> [b] http://www.w3.org/TR/xmlschema-2/#boolean

I'm am under the opinion that this should be changed to a boolean type to
better represent what the check command is really suppose to do, and has
been documented to do.

> 
> 2. Discussion of registry state.
> 
> Known registry states for objects which may be the operands for the <check>
> operator include:
> 
> 	"+"	found or existant
> 	"-"	not found or non-existant
> 	" "	unknown (NeuStar/NeuLevel)
> 	"tbd"	reserved (ICANN)
> 	"tbd"	mechanism lock present (failure diagnostic, pendingDelete, etc)
> 	"tbd"	policy lock present, e.g., "pending" (DRP, etc)
> 	"foo"	defensive registraion (.name specific)
> 	"no"	other issue, tbd, e.g., charter scope (.coop)
> 	"tbd"	unavailable
> 
> It appears that independent of registry-specific policy, more than two values
> are required to express the actual state of objects in the object repository.
> A simplified view might mask all object states to a two-valued representation.
> 

Registrar specific information should not be in the standards draft. That
would not be fesable, and is the reason another attribute should be
created, or possibly returning a value in the <msg> field as to why it is
not available. 

> 3. Extensibility within type and of state.
> 
> Assume a datatype has an N-valued value-space, and for some M < N, N - M of
> the values are allocated. Only N - M values in the value-space are available
> to be reserved for future specification, or reserved for unspecified use, or
> defined to be "undefined".
> 
> In the special case of a boolean type with two values of its value-space
> allocated, N == M == 2, and no extension within the type is possible.
> 
> A similar observation applies to the internal state-space of an object
> repository, and its external representation(s), which may differ, e.g.,
> a common registry for distinct policy-defined or delegated name-spaces.

Creating another attribute on the check responce would allow for responces
limited to the length of the field * the number of characters in the
applicable character set. 

> 
> Eric
> 

Ed Rahn
ItsYourDomain.com

Date: Mon, 24 Sep 2001 16:13:21 -0400
To: Rick H Wesson <[email-masked]>, <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: RE: <check> Response Attribute
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Here are some states that I can think of off the top of my head

- Not available because the domain is restricted due to registry 
policy (for example b.com)
- Not available because the domain is registered to someone else
- Not available because someone paid for it not to be available
- I don't know if it's available
- Available
- Not available because it's reserved
- Not available because it's been deleted, but hasn't been released yet
- Not available because it's a name that isn't registerable by you 
(for example, if only certain registrars have access to certain 
subdomains)
- Available, but the cost is different than you were expecting

I'm sure there are other variations on theme.

I'm not 100% convinced that anything other than a binary state is 
good for the check command, but as long as we're going to make it not 
binary, we should recognize that a) there are many states and b) we 
are not smart enough to predict them all.  So I think I'm with 
Asbjorn on this.

Jordyn

At 11:44 AM -0700 9/24/01, Rick H Wesson wrote:
>Asbjorn,
>
>If you could list more than 8 to 10 diferent reasons then I'd understand
>why we shouldn't enumerate them, thus far only two reasons have been
>listed.
>
>If we just have two cases the I feel we shuld enum,erate them in the
>protocol.
>
>-rick
>
>
>
>On 24 Sep 2001 [email-masked] wrote:
>
>>  Scott,
>>
>>  as Petrick mentioned earlier, we (.NAME) will have socalled "Defensive
>>  Registrations"[1] meaning that we might want to tell the
>>  Registra[r/nt] that this is the reason why a domain is not available.
>>
>>  There might be other reasons for a domain not to be available - a
>>  Registry might for example not allow registrations if the domain name
>>  includes the F-word or other expletives, or other policy-depended
>>  reason.
>>
>>  Since it might be hard to catch all the reasons why a domain name is
>>  "not available" in an enumeration, maybe it should be a free-form
>>  field there after all?!
>>
>>
>>  Asbjorn
>>
>>  [1] 
>>http://www.icann.org/tlds/agreements/name/registry-agmt-appl-03jul01.htm#2
>>
>>  On Sat, 22 Sep 2001 19:33:49 -0400 "Hollenbeck, Scott" wrote:
>>  >> -----Original Message-----
>>  >> From: Patrick [mailto:[email-masked]]
>>  >> Sent: Saturday, September 22, 2001 10:28 AM
>>  >> To: [email-masked]
>>  >> Subject: Re: <check> Response Attribute
>>  >>
>>  >>
>>  >> So the information about why it can not be registered is still
>>  >> useful.
>>  >
>>  >I think Dan Manley suggested this as well.  OK, if multiple people feel it
>>  >would be helpful to provide both a yes/no response and some sort of
>>  >rationale if the answer is "no", should we attempt to enumerate the
>>  >reasons
>>  >for "no" or should we consider free-form (aka server-defined, with some
>>  >defined maximum length) text to describe the rationale?
>>  >
>>  ><Scott/>
>>  >
>>
>>
>>  --
>>   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.
>>

Date: Mon, 24 Sep 2001 16:02:50 -0400
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: "Jordyn A. Buchanan" <[email-masked]>
Subject: Re: <check> Response Attribute
Cc: [email-masked]
Sender: [email-masked]

At 2:46 PM -0400 9/24/01, Eric Brunner-Williams in Portland Maine wrote:
>So now the text is controlling, not the schema?

I'll go out on a limb and say that they should be consistent; if not, 
we should fix that instead of trying to figure out which one wins.

Jordyn

To: [email-masked]
Subject: Re: <check> Response Attribute
Date: Mon, 24 Sep 2001 15:33:42 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

The proposal of 9/21 by the editor of draft-provreg-epp, to make a specific
modification of a schema, is discussed.

There are three related issues. One is the data type returned by an operator.
Another is registry state for the operator's (object) operands. A third is
the extensibility of the first and second.

1. Discussion of types.

The present schema, from draft-ietf-provreg-epp-04.txt (line numbers added),
is:

   2954   <!--
   2955   <check> result type.
   2956   -->
   2957     <simpleType name="checkType">
   2958       <restriction base="token">
   2959         <enumeration value="+"/>
   2960         <enumeration value="-"/>
   2961       </restriction>
   2962     </simpleType>
 
The base type for "token" [t] is "normalizedString" [n], which in turn has
a base type of "string" [s], a primitive datatype. "boolean" [b] is also a
primitive datatype.

Definitional texts:

[Definition:] token represents tokenized strings. The value space of token
is the set of strings that do not contain the line feed (#xA) nor tab (#x9)
characters, that have no leading or trailing spaces (#x20) and that have no
internal sequences of two or more spaces. The lexical space of token is the
set of strings that do not contain the line feed (#xA) nor tab (#x9)
characters, that have no leading or trailing spaces (#x20) and that have no
internal sequences of two or more spaces.

[Definition:]  boolean has the value space required to support
the mathematical concept of binary-valued logic: {true, false}. 

Considered as a question of types, the proposal is to change the tuple used,
the primitive datatype, restricting the value space to the {true,false,1,0}
set, restricting the lexical space, and restricting the set of facets, from
those of "token" to those of "boolean".

[t] http://www.w3.org/TR/xmlschema-2/#token
[n] http://www.w3.org/TR/xmlschema-2/#normalizedString
[s] http://www.w3.org/TR/xmlschema-2/#string
[b] http://www.w3.org/TR/xmlschema-2/#boolean

2. Discussion of registry state.

Known registry states for objects which may be the operands for the <check>
operator include:

	"+"	found or existant
	"-"	not found or non-existant
	" "	unknown (NeuStar/NeuLevel)
	"tbd"	reserved (ICANN)
	"tbd"	mechanism lock present (failure diagnostic, pendingDelete, etc)
	"tbd"	policy lock present, e.g., "pending" (DRP, etc)
	"foo"	defensive registraion (.name specific)
	"no"	other issue, tbd, e.g., charter scope (.coop)
	"tbd"	unavailable

It appears that independent of registry-specific policy, more than two values
are required to express the actual state of objects in the object repository.
A simplified view might mask all object states to a two-valued representation.

3. Extensibility within type and of state.

Assume a datatype has an N-valued value-space, and for some M < N, N - M of
the values are allocated. Only N - M values in the value-space are available
to be reserved for future specification, or reserved for unspecified use, or
defined to be "undefined".

In the special case of a boolean type with two values of its value-space
allocated, N == M == 2, and no extension within the type is possible.

A similar observation applies to the internal state-space of an object
repository, and its external representation(s), which may differ, e.g.,
a common registry for distinct policy-defined or delegated name-spaces.

Eric

To: "Hollenbeck, Scott" <[email-masked]>
cc: [email-masked]
Subject: Re: <check> Response Attribute 
Date: Mon, 24 Sep 2001 14:46:57 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

So now the text is controlling, not the schema?

Date: Mon, 24 Sep 2001 11:44:09 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: <[email-masked]>
cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: <check> Response Attribute
Sender: [email-masked]

Asbjorn,

If you could list more than 8 to 10 diferent reasons then I'd understand
why we shouldn't enumerate them, thus far only two reasons have been
listed.

If we just have two cases the I feel we shuld enum,erate them in the
protocol.

-rick

On 24 Sep 2001 [email-masked] wrote:

> Scott,
>
> as Petrick mentioned earlier, we (.NAME) will have socalled "Defensive
> Registrations"[1] meaning that we might want to tell the
> Registra[r/nt] that this is the reason why a domain is not available.
>
> There might be other reasons for a domain not to be available - a
> Registry might for example not allow registrations if the domain name
> includes the F-word or other expletives, or other policy-depended
> reason.
>
> Since it might be hard to catch all the reasons why a domain name is
> "not available" in an enumeration, maybe it should be a free-form
> field there after all?!
>
>
> Asbjorn
>
> [1] http://www.icann.org/tlds/agreements/name/registry-agmt-appl-03jul01.htm#2
>
> On Sat, 22 Sep 2001 19:33:49 -0400 "Hollenbeck, Scott" wrote:
> >> -----Original Message-----
> >> From: Patrick [mailto:[email-masked]]
> >> Sent: Saturday, September 22, 2001 10:28 AM
> >> To: [email-masked]
> >> Subject: Re: <check> Response Attribute
> >>
> >>
> >> So the information about why it can not be registered is still
> >> useful.
> >
> >I think Dan Manley suggested this as well.  OK, if multiple people feel it
> >would be helpful to provide both a yes/no response and some sort of
> >rationale if the answer is "no", should we attempt to enumerate the
> >reasons
> >for "no" or should we consider free-form (aka server-defined, with some
> >defined maximum length) text to describe the rationale?
> >
> ><Scott/>
> >
>
>
> --
>  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: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: <check> Response Attribute 
Date: Mon, 24 Sep 2001 14:19:23 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Monday, September 24, 2001 1:24 PM
>To: Ed Rahn
>Cc: Eric Brunner-Williams in Portland Maine; [email-masked];
>[email-masked]
>Subject: Re: <check> Response Attribute 
>
>
>Ed,
>
>Please see my query of th 21st to Scott, and his reply.

I believe my response was consistent with Ed's observation.  Here's the
schema slice:

<simpleType name="checkType">
  <restriction base="token">
    <enumeration value="+"/>
    <enumeration value="-"/>
  </restriction>
</simpleType>

There are only two alternatives.

<Scott/>

To: Ed Rahn <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: <check> Response Attribute 
Date: Mon, 24 Sep 2001 13:24:23 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

Please see my query of th 21st to Scott, and his reply.

Eric

Date: Mon, 24 Sep 2001 11:35:58 -0500 (CDT)
From: Ed Rahn <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: [email-masked]
Subject: Re: <check> Response Attribute
Sender: [email-masked]

Eric, 
	According to the epp 04 draft, "value identifies the object as
either "+" for a known object or "-" for an unknown object.", the implimentation
below is incorrect. 

For what is suppose to be represented, object unknown or object know, a
boolean type is completely appropriate.

Ed Rahn
ItsYourDomain.com

On Mon, 24 Sep 2001, Eric Brunner-Williams in Portland Maine wrote:

> A data point, our use of the token data type in our RTK, as of the 0.2.1
> release version identifier (9/21/01).
> 
> NeuLevel-RTK.0.2.1/src/
> 
> 	../c++/src/epp/core/response/EppResponseDataCheck.cpp
> 
> 	...
> class EPP_EXPORT EppResponseDataCheck : public EppResponseData
> {
> protected:
> 	...
> public:
>         /**
>          * Status for checking the existance of an object in the registry
>          */
>         static const char * UNKNOWN;
>         /**
>          * Status for checking the existance of an object in the registry
>          */
>         static const char * FOUND;
>         /**
>          * Status for checking the existance of an object in the registry
>          */
>         static const char * NOT_FOUND;
> 	...
> }
> 
> NeuLevel-RTK.0.2.1/src/
> 
> 	../java/src/com/neulevel/epp/core/response/EppResponseDataCheck.java
> 
> 	...
> abstract public class EppResponseDataCheck extends EppResponseData
> {
> 	/**
>          * Status for checking the existance of an object in the registry
>          */
> 	public static final String UNKNOWN   = " ";
>         /**
>          * Status for checking the existance of an object in the registry
>          */
>         public static final String FOUND     = "+";
>         /**
>          * Status for checking the existance of an object in the registry
>          */
>         public static final String NOT_FOUND = "-";
> 	...
> }
> 
> The data type (token) is appropriate.
> 
> The value space is defined by the registry, and may be composed of general,
> and specific, values.
> 
> A boolean type is inappropriate.
> 
> Eric
> 

To: [email-masked]
Subject: Re: <check> Response Attribute
Date: Mon, 24 Sep 2001 12:14:00 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

A data point, our use of the token data type in our RTK, as of the 0.2.1
release version identifier (9/21/01).

NeuLevel-RTK.0.2.1/src/

	../c++/src/epp/core/response/EppResponseDataCheck.cpp

	...
class EPP_EXPORT EppResponseDataCheck : public EppResponseData
{
protected:
	...
public:
        /**
         * Status for checking the existance of an object in the registry
         */
        static const char * UNKNOWN;
        /**
         * Status for checking the existance of an object in the registry
         */
        static const char * FOUND;
        /**
         * Status for checking the existance of an object in the registry
         */
        static const char * NOT_FOUND;
	...
}

NeuLevel-RTK.0.2.1/src/

	../java/src/com/neulevel/epp/core/response/EppResponseDataCheck.java

	...
abstract public class EppResponseDataCheck extends EppResponseData
{
	/**
         * Status for checking the existance of an object in the registry
         */
	public static final String UNKNOWN   = " ";
        /**
         * Status for checking the existance of an object in the registry
         */
        public static final String FOUND     = "+";
        /**
         * Status for checking the existance of an object in the registry
         */
        public static final String NOT_FOUND = "-";
	...
}

The data type (token) is appropriate.

The value space is defined by the registry, and may be composed of general,
and specific, values.

A boolean type is inappropriate.

Eric

Date: Mon, 24 Sep 2001 12:12:48 -0400
From: Daniel Manley <[email-masked]>
To: Ed Rahn <[email-masked]>
CC: [email-masked]
Subject: Re: <check> Response Attribute
Sender: [email-masked]

Oh, I agree.  I mentioned before that "x" should still only by true or 
false.  A second attribute could be added to provide the reason for a 
true response (true meaning "exists in the registry").

Dan

Ed Rahn wrote:

>As this would be registry specific, I don't think it  should be the
>only thing returned. When doing a check, x should be yes or no. The reason
>why should either be another attribute with a reason why, or a new result
>code could be created and the reason could be returned in the msg tag.
>
>Ed Rahn
>ItsYourDomain.com
>
>"The Wholesale Registrar"
>
>On Mon, 24 Sep 2001, Daniel Manley wrote:
>
>>That might also come in handy for objects that are "pendingDelete".
>>
>>Dan
>>
>>Hollenbeck, Scott wrote:
>>
>>>>-----Original Message-----
>>>>From: [email-masked]
>>>>[mailto:[email-masked]]
>>>>Sent: Sunday, September 23, 2001 7:27 PM
>>>>To: [email-masked]
>>>>Subject: RE: <check> Response Attribute
>>>>
>>>>
>>>>On 23 Sep 01, at 15:09, Hollenbeck, Scott wrote:
>>>>
>>>>>>I think it would be helpfull if unavailable could return a reason.
>>>>>>
>>>>>OK, I agree.  I can think of two based on the discussion 
>>>>>
>>>>that's taken place:
>>>>
>>>>>"taken" (or some other word that means "already registered"), and
>>>>>"reserved".  Are there any others, and if so what do they mean?
>>>>>
>>>>Would there be a support for "unknown"?
>>>>We have a situation in which the status of the domain
>>>>is "pending". (eg. dispute, will be closed - just waiting
>>>>for confirmation.)
>>>>Or perhaps this can be lumped as "taken"?
>>>>(but will be available in the next day or so?)
>>>>
>>>Budi,
>>>
>>>"unknown" seems to defeat the purpose for providing a reason for
>>>unavailability, but maybe "dispute" makes sense.  Would it help registrars
>>>to know that something is unavailable due to a dispute, with the implication
>>>being that it may become available "soon"?
>>>
>>><Scott/>
>>>
>>
>>
>>
>

Date: Mon, 24 Sep 2001 10:59:05 -0500 (CDT)
From: Ed Rahn <[email-masked]>
To: Daniel Manley <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: <check> Response Attribute
Sender: [email-masked]

As this would be registry specific, I don't think it  should be the
only thing returned. When doing a check, x should be yes or no. The reason
why should either be another attribute with a reason why, or a new result
code could be created and the reason could be returned in the msg tag.

Ed Rahn
ItsYourDomain.com

"The Wholesale Registrar"

On Mon, 24 Sep 2001, Daniel Manley wrote:

> That might also come in handy for objects that are "pendingDelete".
> 
> Dan
> 
> Hollenbeck, Scott wrote:
> 
> >>-----Original Message-----
> >>From: [email-masked]
> >>[mailto:[email-masked]]
> >>Sent: Sunday, September 23, 2001 7:27 PM
> >>To: [email-masked]
> >>Subject: RE: <check> Response Attribute
> >>
> >>
> >>On 23 Sep 01, at 15:09, Hollenbeck, Scott wrote:
> >>
> >>>>I think it would be helpfull if unavailable could return a reason.
> >>>>
> >>>OK, I agree.  I can think of two based on the discussion 
> >>>
> >>that's taken place:
> >>
> >>>"taken" (or some other word that means "already registered"), and
> >>>"reserved".  Are there any others, and if so what do they mean?
> >>>
> >>Would there be a support for "unknown"?
> >>We have a situation in which the status of the domain
> >>is "pending". (eg. dispute, will be closed - just waiting
> >>for confirmation.)
> >>Or perhaps this can be lumped as "taken"?
> >>(but will be available in the next day or so?)
> >>
> >
> >Budi,
> >
> >"unknown" seems to defeat the purpose for providing a reason for
> >unavailability, but maybe "dispute" makes sense.  Would it help registrars
> >to know that something is unavailable due to a dispute, with the implication
> >being that it may become available "soon"?
> >
> ><Scott/>
> >
> 
> 
> 
> 

Date: 24 Sep 2001 15:55:36 -0000
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: RE: <check> Response Attribute
Sender: [email-masked]

Scott,

as Petrick mentioned earlier, we (.NAME) will have socalled "Defensive Registrations"[1] meaning that we might want to tell the Registra[r/nt] that this is the reason why a domain is not available.

There might be other reasons for a domain not to be available - a Registry might for example not allow registrations if the domain name includes the F-word or other expletives, or other policy-depended reason.

Since it might be hard to catch all the reasons why a domain name is "not available" in an enumeration, maybe it should be a free-form field there after all?!

Asbjorn

[1] http://www.icann.org/tlds/agreements/name/registry-agmt-appl-03jul01.htm#2

On Sat, 22 Sep 2001 19:33:49 -0400 "Hollenbeck, Scott" wrote:
>> -----Original Message-----
>> From: Patrick [mailto:[email-masked]]
>> Sent: Saturday, September 22, 2001 10:28 AM
>> To: [email-masked]
>> Subject: Re: <check> Response Attribute
>> 
>> 
>> So the information about why it can not be registered is still
>> useful.
>
>I think Dan Manley suggested this as well.  OK, if multiple people feel it
>would be helpful to provide both a yes/no response and some sort of
>rationale if the answer is "no", should we attempt to enumerate the 
>reasons
>for "no" or should we consider free-form (aka server-defined, with some
>defined maximum length) text to describe the rationale?
>
><Scott/>
>

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

Date: Mon, 24 Sep 2001 12:02:47 -0400
From: Daniel Manley <[email-masked]>
To: Thomas Corte <[email-masked]>
CC: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Command Recovery
Sender: [email-masked]

Thomas Corte wrote:

>Hello,
>
>On Thu, 20 Sep 2001, Daniel Manley wrote:
>
>>Thomas,
>>
>>I see your point but I think that it's not right to not enforce
>>uniqueness and then throw an error if the queried identifier is not
>>unique.  The server should probably enforce uniqueness right off the bat.
>>
>
>So the server would throw an error if it receives a different command
>with the same trid?
>This would be nice, but it has been argued that enforcing uniqueness
>at the server side could involve too expensive lookup operations for
>each command, especially for read-only commands which do not require the
>discussed recovery.
>
Yes, that's certainly a good point.  Then transaction objects would only 
be recorded for transform actions.  Uniqueness would not be enforced for 
query operations since they don't change the state of objects in the 
registry.

But given Scott's last reponse to this thread, it looks like this is 
turning out to be a "nice-to-have" vs. "expensive-to-implement" issue. 
 But would it be that big burden to enforce uniqueness?  Would it be 
fair to use the example of storing the transactions in a table with a 
unique index on registrar id and client trid?  DB's are usually pretty 
efficient at rejecting inserts in duplicate keys.  Or are implementation 
discussions out of scope in this discussion?

Date: Mon, 24 Sep 2001 10:06:11 -0400
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: <check> Response Attribute
Sender: [email-masked]

That might also come in handy for objects that are "pendingDelete".

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]
>>Sent: Sunday, September 23, 2001 7:27 PM
>>To: [email-masked]
>>Subject: RE: <check> Response Attribute
>>
>>
>>On 23 Sep 01, at 15:09, Hollenbeck, Scott wrote:
>>
>>>>I think it would be helpfull if unavailable could return a reason.
>>>>
>>>OK, I agree.  I can think of two based on the discussion 
>>>
>>that's taken place:
>>
>>>"taken" (or some other word that means "already registered"), and
>>>"reserved".  Are there any others, and if so what do they mean?
>>>
>>Would there be a support for "unknown"?
>>We have a situation in which the status of the domain
>>is "pending". (eg. dispute, will be closed - just waiting
>>for confirmation.)
>>Or perhaps this can be lumped as "taken"?
>>(but will be available in the next day or so?)
>>
>
>Budi,
>
>"unknown" seems to defeat the purpose for providing a reason for
>unavailability, but maybe "dispute" makes sense.  Would it help registrars
>to know that something is unavailable due to a dispute, with the implication
>being that it may become available "soon"?
>
><Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: <check> Response Attribute
Date: Mon, 24 Sep 2001 09:03:25 -0400
Sender: [email-masked]

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]
>Sent: Sunday, September 23, 2001 7:27 PM
>To: [email-masked]
>Subject: RE: <check> Response Attribute
>
>
>On 23 Sep 01, at 15:09, Hollenbeck, Scott wrote:
>
>> > I think it would be helpfull if unavailable could return a reason.
>> 
>> OK, I agree.  I can think of two based on the discussion 
>that's taken place:
>> "taken" (or some other word that means "already registered"), and
>> "reserved".  Are there any others, and if so what do they mean?
>
>Would there be a support for "unknown"?
>We have a situation in which the status of the domain
>is "pending". (eg. dispute, will be closed - just waiting
>for confirmation.)
>Or perhaps this can be lumped as "taken"?
>(but will be available in the next day or so?)

Budi,

"unknown" seems to defeat the purpose for providing a reason for
unavailability, but maybe "dispute" makes sense.  Would it help registrars
to know that something is unavailable due to a dispute, with the implication
being that it may become available "soon"?

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bruce Tonkin'" <[email-masked]>, [email-masked]
Subject: RE: ".au" registry technical specification
Date: Mon, 24 Sep 2001 08:13:12 -0400
Sender: [email-masked]

Bruce,

I read the specification slightly differently: they don't wish to mandate
use of the current IETF specs because there is no standard yet, and there
aren't any open implementations.  Both issues seem more-or-less reasonable
given that we haven't yet produced any draft standards.  I wouldn't want to
mandate anything either until things were more solid.

FWIW there _is_ at least one open client implementation being done on
SourceForge; perhaps Dan Manley or Rick Wesson can fill in details or
provide insights into that implementation and any server-side work that's
being done.

<Scott/>

>-----Original Message-----
>From: Bruce Tonkin [mailto:[email-masked]]
>Sent: Monday, September 24, 2001 4:05 AM
>To: [email-masked]
>Subject: ".au" registry technical specification
>
>
>Monash University in Australia has written a technical 
>specification for the
>".au" registry.
>
>See:
>http://www.auda.org.au/transition/Registry_Tech_Spec_101.pdf
>
>Note section 2.2, where a new registry/registrar protocol is 
>proposed on the
>basis that the barriers are too high for registrars to use 
>EPP, and there
>are no open implementations of EPP available.
>
>I would be interested in the views of members of the working 
>group on this
>issue.
>
>If it is too hard to implement the IETF standard there will be 
>little take
>up outside a few gtlds.
>
>Bruce Tonkin
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Stuart Marsden'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <check> Response Attribute
Date: Mon, 24 Sep 2001 07:47:32 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Stuart Marsden [mailto:[email-masked]]
>Sent: Monday, September 24, 2001 4:07 AM
>To: [email-masked]
>Subject: RE: <check> Response Attribute
>
>
>For a restricted domain (eg dot coop) you would have "no" for lack of
>registrant eligibility

Does that make sense in the context of a <check> command, though, when no
registrant info is provided as part of the <check>?

<Scott/>

From: "Stuart Marsden" <[email-masked]>
To: <[email-masked]>
Subject: RE: <check> Response Attribute
Date: Mon, 24 Sep 2001 09:07:08 +0100
Importance: Normal
Sender: [email-masked]

For a restricted domain (eg dot coop) you would have "no" for lack of
registrant eligibility

Stuart Marsden

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hollenbeck, Scott
Sent: 23 September 2001 00:34
To: 'Patrick'; [email-masked]
Subject: RE: <check> Response Attribute

> -----Original Message-----
> From: Patrick [mailto:[email-masked]]
> Sent: Saturday, September 22, 2001 10:28 AM
> To: [email-masked]
> Subject: Re: <check> Response Attribute
> 
> 
> So the information about why it can not be registered is still
> useful.

I think Dan Manley suggested this as well.  OK, if multiple people feel
it
would be helpful to provide both a yes/no response and some sort of
rationale if the answer is "no", should we attempt to enumerate the
reasons
for "no" or should we consider free-form (aka server-defined, with some
defined maximum length) text to describe the rationale?

<Scott/>

From: Bruce Tonkin <[email-masked]>
To: [email-masked]
Subject: ".au" registry technical specification
Date: Mon, 24 Sep 2001 18:04:53 +1000
Sender: [email-masked]

Monash University in Australia has written a technical specification for the
".au" registry.

See:
http://www.auda.org.au/transition/Registry_Tech_Spec_101.pdf

Note section 2.2, where a new registry/registrar protocol is proposed on the
basis that the barriers are too high for registrars to use EPP, and there
are no open implementations of EPP available.

I would be interested in the views of members of the working group on this
issue.

If it is too hard to implement the IETF standard there will be little take
up outside a few gtlds.

Bruce Tonkin

From: [email-masked]
To: [email-masked]
Date: Mon, 24 Sep 2001 06:27:20 +0700
Subject: RE: <check> Response Attribute
Sender: [email-masked]

On 23 Sep 01, at 15:09, Hollenbeck, Scott wrote:

> > I think it would be helpfull if unavailable could return a reason.
> 
> OK, I agree.  I can think of two based on the discussion that's taken place:
> "taken" (or some other word that means "already registered"), and
> "reserved".  Are there any others, and if so what do they mean?

Would there be a support for "unknown"?
We have a situation in which the status of the domain
is "pending". (eg. dispute, will be closed - just waiting
for confirmation.)
Or perhaps this can be lumped as "taken"?
(but will be available in the next day or so?)

Regards
-- budi

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: <check> Response Attribute
Date: Sun, 23 Sep 2001 15:09:31 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Saturday, September 22, 2001 7:55 PM
> To: Hollenbeck, Scott
> Cc: 'Patrick'; [email-masked]
> Subject: RE: <check> Response Attribute
> 
> 
> 
> I think it would be helpfull if unavailable could return a reason.

OK, I agree.  I can think of two based on the discussion that's taken place:
"taken" (or some other word that means "already registered"), and
"reserved".  Are there any others, and if so what do they mean?

<Scott/>

Date: Sat, 22 Sep 2001 16:55:05 -0700 (PDT)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Patrick'" <[email-masked]>, <[email-masked]>
Subject: RE: <check> Response Attribute
Sender: [email-masked]

Scott,

I think it would be helpfull if unavailable could return a reason.

-rick

On Sat, 22 Sep 2001, Hollenbeck, Scott wrote:

> > -----Original Message-----
> > From: Patrick [mailto:[email-masked]]
> > Sent: Saturday, September 22, 2001 10:28 AM
> > To: [email-masked]
> > Subject: Re: <check> Response Attribute
> >
> >
> > So the information about why it can not be registered is still
> > useful.
>
> I think Dan Manley suggested this as well.  OK, if multiple people feel it
> would be helpful to provide both a yes/no response and some sort of
> rationale if the answer is "no", should we attempt to enumerate the reasons
> for "no" or should we consider free-form (aka server-defined, with some
> defined maximum length) text to describe the rationale?
>
> <Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Patrick'" <[email-masked]>, [email-masked]
Subject: RE: <check> Response Attribute
Date: Sat, 22 Sep 2001 19:33:49 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Patrick [mailto:[email-masked]]
> Sent: Saturday, September 22, 2001 10:28 AM
> To: [email-masked]
> Subject: Re: <check> Response Attribute
> 
> 
> So the information about why it can not be registered is still
> useful.

I think Dan Manley suggested this as well.  OK, if multiple people feel it
would be helpful to provide both a yes/no response and some sort of
rationale if the answer is "no", should we attempt to enumerate the reasons
for "no" or should we consider free-form (aka server-defined, with some
defined maximum length) text to describe the rationale?

<Scott/>

Date: Sat, 22 Sep 2001 16:28:09 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <check> Response Attribute
Organization: Gandi
Sender: [email-masked]

On Fri, Sep 21, 2001 at 05:10:47PM -0400, Mike Lampson took time to write:
> Maybe it's too late for this, but what us Registrars need to know is whether
> the name is available for registration, not if it exists.  If a name cannot
> be registered, I don't really care if it can't be registered because it
> already exists or because it is reserved.

Registrars maybe not, but clients sure.
As Registrar I would like to be able to tell my customer that if this
domain can not be registered it is for a reason, being reserverd for
example (ie. you will never be able to get that one, please change
your mind), or just being registered by someone else previously (in
that case we can tell the client to see if the current owner wish to
sell).

So the information about why it can not be registered is still
useful.

For .NAME for example they are Defensive Registrations.
It would be great, when registering a domain name that fall under a
Defensive Registration to have back the answer : no, domain name not
available *because* such and such Defensive Registration.

In short the reason seems helpful to me, and should be included.
Client code (Registrars) will use it or not like they wish, but if
the Server (Registry) can send it, why not do it.

Patrick Mevzek
Gandi.

Date: Fri, 21 Sep 2001 17:10:47 -0400
From: Mike Lampson <[email-masked]>
Subject: Re: <check> Response Attribute
To: "'ietf-provregcafaxse'" <[email-masked]>
Cc: Daniel Manley <[email-masked]>
Sender: [email-masked]

Maybe it's too late for this, but what us Registrars need to know is whether
the name is available for registration, not if it exists.  If a name cannot
be registered, I don't really care if it can't be registered because it
already exists or because it is reserved.

Regards,

Mike Lampson
The Registry at Info Avenue, LLC
(803) 802-6584

----- Original Message -----
From: "Daniel Manley" <[email-masked]>
To: "'ietf-provregcafaxse'" <[email-masked]>
Sent: Friday, September 21, 2001 4:59 PM
Subject: Re: <check> Response Attribute

I tend to agree that "exists" is a black-and-white state that gets a
boolean setting.  Maybe you'd want an optional "status" or "why"
attribute that could contain the strings "reserved", "restricted", etc...

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Eric Brunner-Williams in Portland Maine
>>[mailto:[email-masked]]
>>Sent: Friday, September 21, 2001 11:17 AM
>>To: Hollenbeck, Scott
>>Cc: [email-masked]'; [email-masked]
>>Subject: Re: <check> Response Attribute
>>
>>
>>Scott,
>>
>>You propose to restrict the type of <check> from an enumerated extensible
>>set (token) to a enumerated inextensible (boolean) set.
>>
>
>No, I've suggested that we replace what has been a kludge for a boolean
>response with a true boolean response.
>
>>How do you propose we handle requirements for "reserved" domain names?
>>
>
>The <check> command's purpose is to answer the question "does this object
>exist in the repository"; the answer to that question is binary.  If a name
>has been registered the answer should be "yes".
>
>I don't know which/whose requirements you're referring to.  If you're
>alluding to a specific server operator's need to return information beyond
a
>yes/no response I'd propose use of the extension mechanism.
>
><Scott/>
>

Date: Fri, 21 Sep 2001 16:59:49 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: <check> Response Attribute
Sender: [email-masked]

I tend to agree that "exists" is a black-and-white state that gets a 
boolean setting.  Maybe you'd want an optional "status" or "why" 
attribute that could contain the strings "reserved", "restricted", etc...

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Eric Brunner-Williams in Portland Maine
>>[mailto:[email-masked]]
>>Sent: Friday, September 21, 2001 11:17 AM
>>To: Hollenbeck, Scott
>>Cc: [email-masked]'; [email-masked]
>>Subject: Re: <check> Response Attribute 
>>
>>
>>Scott,
>>
>>You propose to restrict the type of <check> from an enumerated extensible
>>set (token) to a enumerated inextensible (boolean) set.
>>
>
>No, I've suggested that we replace what has been a kludge for a boolean
>response with a true boolean response.
>
>>How do you propose we handle requirements for "reserved" domain names?
>>
>
>The <check> command's purpose is to answer the question "does this object
>exist in the repository"; the answer to that question is binary.  If a name
>has been registered the answer should be "yes".
>
>I don't know which/whose requirements you're referring to.  If you're
>alluding to a specific server operator's need to return information beyond a
>yes/no response I'd propose use of the extension mechanism.
>
><Scott/>
>

Date: Fri, 21 Sep 2001 15:48:03 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: Klaus Malorny <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Thomas Corte'" <[email-masked]>, <[email-masked]>
Subject: Re: interpretation of 'EPP idempotency'
Sender: [email-masked]

Hi Scott,

I have to agree with Klaus here.  While I was writing my email yesterday
it did occur to me that the commands are all by nature idempotent
(because we don't alllow duplicate value in vector fields like domain
nameservers or contact statuses) I really didn't imagine that that was the
intended solution to the problem.

Not only is it potentially difficult to implement; from a design
perspective it ties your transaction management (well, I'm putting
idempotency under the broad heading of transaction management) to your
business rules and the structure of your commands.  Remember also, that in
the long run, the epp is supposed to be a generic registration protocol.
What if I define an epp extention to represent some other kind of object
which can have non-unique lists of subobjects.  In this case it would make
a difference whether I did an update once or twice.  This would put the
burden of ensuring idempotency on each extention (like renew in the
case of domain) rather than on the base protocol itself which is a much
more uniform and elegant solution.

Regards,
Sheer

On Tue, 18 Sep 2001, Klaus Malorny wrote:

> "Hollenbeck, Scott" wrote:
> >
>
> > No, this can't happen.  Every contact object has an associated identifier
> > (see the <contact:id> element described in sections 3.1.2 and 3.2.1 of
> > contact-02) that MUST be unique.  In the scenario you described, the first
> > command will succeed.  The repeat will fail.
> >
> > <Scott/>
>
>
> Hi Scott,
>
> your solution surely works, but, from a design perspective, this is IMHO a bad
> solution. Each request has to take care for itself not to violate the
> idempotency constraint. E.g. the contact create command e.g. requires to
> specify a <contact:id> to solve the idempotency problem, but the renew command
> requires something quite different, namely the current expiration date, which
> does not make any sense for the semantics of the command itself. There is no
> uniform handling in the protocol. There is no chance to write software that
> deals with a communication interruption without knowing in detail what a
> specific request does and what the possible answers of the server are. This is
> just a pain. There is no way to ask the server "did you perform the command I
> sent to you?". Even if the replay of a command does not change the state of
> the server, the client will get different answers. And these answers are
> indistinguishable. What does a "domain exists" message really mean to the
> client? The client cannot determine whether the domain was created by himself
> or by another instance running in parallel that accidentically wants to create
> the very same domain? How should the client determine whether to create a
> mirror object in the own database? The only solution would be that the client
> issues a inquire command and compares the data returned with the own data,
> e.g. compare all the contacts and hosts. Even in this case it is not
> guaranteed that the client's database becomes corrupted.
>
> Instead of building upon idempotency constraints which affect the design of
> each command, it would be better to have a separate layer that deals with
> problems that appear in a client-server architecture. The way we do it in the
> CORE SRS Protocol is one solution, it is quite simple and it works.
>
>
> Klaus Malorny
>
>
> ___________________________________________________________________________
>      |       |
>      | knipp |                   Knipp  Medien und Kommunikation GmbH
>       -------                           Technologiepark
>                                         Martin-Schmeisser-Weg 9
>      Dipl. Inf. Klaus Malorny           44227 Dortmund
>      [email-masked]             Tel. +49 231 9703 0
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <check> Response Attribute 
Date: Fri, 21 Sep 2001 15:42:21 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 3:18 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: <check> Response Attribute 
> 
> 
> > Given that the <check> command is documented ...
> 
> in two places, the text and the schema. Which is controlling?

The schema is the formal specification.  The -04 schema includes only two
alternatives for the value of the "x" attribute: "+" for a known object and
"-" for an unknown object; the text is consistent in this regard.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: <check> Response Attribute 
Date: Fri, 21 Sep 2001 15:17:34 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Given that the <check> command is documented ...

in two places, the text and the schema. Which is controlling?

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <check> Response Attribute 
Date: Fri, 21 Sep 2001 14:42:59 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 2:39 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: <check> Response Attribute 
> 
> 
> I prefer the kludge. It has the advantage of being extensible.
>
> Did you have some other motivation than simplification for the sake
> of consistency?

No, no other motivation.  I prefer to call a boolean a boolean because other
booleans elsewhere in the protocol are defined as such.  It's that
consistency thing again.

Given that the <check> command is documented to produce binary results at a
minimum (with additional info possibly included via the extension
mechanism), it sounds like you're suggesting that we modify the definition
of binary.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Thomas Corte'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Command Recovery
Date: Fri, 21 Sep 2001 14:36:45 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Thomas Corte [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 6:41 AM
> To: Daniel Manley
> Cc: Hollenbeck, Scott; [email-masked]
> Subject: Re: Command Recovery
> 
> Using the transmission date would require client and server to
> agree on the *exact date* for a later status query match. Afaik,
> EPP currently does not include transmission of the current date,
> neither by the client nor by the server. Therefore, usage of the
> date might be not feasible here.
> Using the operation type (in addition to the registrar id)
> to reduce the client trid namespace seems reasonable.

Thomas,

Given that all dates are exchanged in UTC it shouldn't be a problem for the
client (who knows when the command was allegedly sent) and server to be in
synch, but if they're not, yes, this might be an issue.  I can also see
where it might be an issue if a date boundary is crossed due to normal
network latency, so I don't mind leaving it out if folks think it introduces
a point of potential confusion.

> However, I still don't consider it a big problem to require unique
> trids from the client. After all, the mechanism we are discussing
> facilitates the client's recovery issues, so it shouldn't burden
> the client too much to put trid uniqueness into it's responsibility.

I wouldn't mind adding text to the specs to RECOMMEND that clients enforce
TRID uniqueness on their end, but I don't want such text to imply that the
server MUST enforce uniqueness if the client makes mistakes.  That's where
the burden can get ugly.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: <check> Response Attribute 
Date: Fri, 21 Sep 2001 14:39:14 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

I prefer the kludge. It has the advantage of being extensible.

Did you have some other motivation than simplification for the sake
of consistency?

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Another To-Do Thought 
Date: Fri, 21 Sep 2001 14:21:10 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 12:04 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'; [email-masked]
> Subject: Re: Another To-Do Thought 
> 
> 
> Scott,
> 
> Hmm.
> 
> Assume we've a base or core or MUST spec. E.g., epp-04 et seq.
> 
> Assume we've one or more extensions or MAY spec(s). E.g., beep,
containers,
> push, data protection, et seq.
> 
> Assume someone has something for which no standards-track I-D exists which
> normatively defines. E.g., trademark (.info registry private xml blob, any
> errors are mine, and copyrighted).
> 
> Are r-*-private thingees <unspec>, or are they <extension>?

If the thingees are shared between client and server and not part of the
base specs, but they exist as a some form of additional elements added to
the protocol, they are extensions.  I don't think the form of documentation
(I-D, RFC, proprietary document) matters, as long as there's a schema
somewhere that defines the thingee.  If a schema exists, the thingee isn't
unspecified by definition.

As I said in my original note, I don't think "unspec" conveys the real
purpose of the element.  It's a place to add extensions, and as such using
"extension" seems more appropriate.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <check> Response Attribute 
Date: Fri, 21 Sep 2001 14:09:36 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 11:17 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'; [email-masked]
> Subject: Re: <check> Response Attribute 
> 
> 
> Scott,
> 
> You propose to restrict the type of <check> from an enumerated extensible
> set (token) to a enumerated inextensible (boolean) set.

No, I've suggested that we replace what has been a kludge for a boolean
response with a true boolean response.

> How do you propose we handle requirements for "reserved" domain names?

The <check> command's purpose is to answer the question "does this object
exist in the repository"; the answer to that question is binary.  If a name
has been registered the answer should be "yes".

I don't know which/whose requirements you're referring to.  If you're
alluding to a specific server operator's need to return information beyond a
yes/no response I'd propose use of the extension mechanism.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Another To-Do Thought 
Date: Fri, 21 Sep 2001 12:03:54 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

Hmm.

Assume we've a base or core or MUST spec. E.g., epp-04 et seq.

Assume we've one or more extensions or MAY spec(s). E.g., beep, containers,
push, data protection, et seq.

Assume someone has something for which no standards-track I-D exists which
normatively defines. E.g., trademark (.info registry private xml blob, any
errors are mine, and copyrighted).

Are r-*-private thingees <unspec>, or are they <extension>?

I prefer to retain the present form of <unspec>, at least for things I don't
know about, assuming all I know is in a current I-D, and eventual RFC.

Eric

> Would anyone care if the <unspec> element tag was changed from "unspec" to
> "extension"?  I think "extension" makes the real meaning much easier to
> understand.

To: Chris Cowherd <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: <check> Response Attribute 
Date: Fri, 21 Sep 2001 11:57:25 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> I would say that "reserved" domain names are not available.

Help me to understand. Does "reserved" mean "exits" or does "reserved"
mean "doesn't exist"? Why is either of these better than "reserved"?

Here are my concerns:

1. substitution of an inextensible type for an extensible type.

2. over-specification of the <check> use-case.

Eric

From: Chris Cowherd <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <check> Response Attribute 
Date: Fri, 21 Sep 2001 08:52:57 -0700
Sender: [email-masked]

I would say that "reserved" domain names are not available.

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Fri, September 21, 2001 8:17 AM
To: Hollenbeck, Scott
Cc: [email-masked]'; [email-masked]
Subject: Re: <check> Response Attribute 

Scott,

You propose to restrict the type of <check> from an enumerated extensible
set (token) to a enumerated inextensible (boolean) set.

How do you propose we handle requirements for "reserved" domain names?

Eric

> The <check> command response currently returns an element attribute to
note
> if an object exists.  The value space of this attribute is really boolean,
> but the current schema uses a "+" to note "exists" and a "-" to note
> "doesn't exist".  I'd like to propose a simplification for the sake of
> consistency with other boolean attributes, changing the type of the
> attribute to "boolean", an XML Schema data type.  This would mean that the
> acceptable values become "1" and "true" for "exists" , and "0" and "false"
> for "doesn't exist".

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: <check> Response Attribute 
Date: Fri, 21 Sep 2001 11:17:28 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

You propose to restrict the type of <check> from an enumerated extensible
set (token) to a enumerated inextensible (boolean) set.

How do you propose we handle requirements for "reserved" domain names?

Eric

> The <check> command response currently returns an element attribute to note
> if an object exists.  The value space of this attribute is really boolean,
> but the current schema uses a "+" to note "exists" and a "-" to note
> "doesn't exist".  I'd like to propose a simplification for the sake of
> consistency with other boolean attributes, changing the type of the
> attribute to "boolean", an XML Schema data type.  This would mean that the
> acceptable values become "1" and "true" for "exists" , and "0" and "false"
> for "doesn't exist".

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: <check> Response Attribute
Date: Fri, 21 Sep 2001 07:55:58 -0400
Sender: [email-masked]

Another small item that could stand cleaning up...

The <check> command response currently returns an element attribute to note
if an object exists.  The value space of this attribute is really boolean,
but the current schema uses a "+" to note "exists" and a "-" to note
"doesn't exist".  I'd like to propose a simplification for the sake of
consistency with other boolean attributes, changing the type of the
attribute to "boolean", an XML Schema data type.  This would mean that the
acceptable values become "1" and "true" for "exists" , and "0" and "false"
for "doesn't exist".

<Scott/>

Date: Fri, 21 Sep 2001 12:41:12 +0200 (MESZ)
From: Thomas Corte <[email-masked]>
To: Daniel Manley <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: Re: Command Recovery
Sender: [email-masked]

Hello,

On Thu, 20 Sep 2001, Daniel Manley wrote:

> Thomas,
>
> I see your point but I think that it's not right to not enforce
> uniqueness and then throw an error if the queried identifier is not
> unique.  The server should probably enforce uniqueness right off the bat.

So the server would throw an error if it receives a different command
with the same trid?
This would be nice, but it has been argued that enforcing uniqueness
at the server side could involve too expensive lookup operations for
each command, especially for read-only commands which do not require the
discussed recovery.

On Thu, 20 Sep 2001, Bason, Chris wrote:

> We could avoid requiring client trid uniqueness by making
> a status command that provided additional options for the
> query. For example, if a registrar needed to perform a status
> command for a specific client trid, they could also pass
> in the operation that was being performed (e.g. CREATE, UPDATE,
> etc.) and the date that the command was transmitted.
>
> The registry would then have 4 attributes to check for the
> possible client trid being requested: registrar Id, operation,
> transaction date and client trid. If multiple rows were found
> for this combination then the status command would return a
> multi-row result set. It would then be up to the registrar to
> process the result set returned to determine whether the transaction
> they are looking for was processed.

Using the transmission date would require client and server to
agree on the *exact date* for a later status query match. Afaik,
EPP currently does not include transmission of the current date,
neither by the client nor by the server. Therefore, usage of the
date might be not feasible here.
Using the operation type (in addition to the registrar id)
to reduce the client trid namespace seems reasonable.

However, I still don't consider it a big problem to require unique
trids from the client. After all, the mechanism we are discussing
facilitates the client's recovery issues, so it shouldn't burden
the client too much to put trid uniqueness into it's responsibility.

Regards,

_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        D-44227 Dortmund
     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
     [email-masked]              Fax: +49-231-9703-200

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: <status> Response
Date: Thu, 20 Sep 2001 15:32:45 -0400
Sender: [email-masked]

I should have asked this in my earlier note: what should be returned in
response to a <status> command?

I can see echoing back the transaction's clTRID if recognized by the server,
and an indication of success or failure.  Anything else?

At first I thought it might be a good idea to return the svTRID as well, but
this would essentially force implementations to keep all svTRIDs in a
database.  If an implementation logs some or all TRIDs instead of keeping
them in a database, getting to them to form the response won't really be
feasible.

<Scott/>

Date: Thu, 20 Sep 2001 12:41:18 -0400
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "Bason, Chris" <[email-masked]>, [email-masked]
Subject: Re: Command Recovery
Sender: [email-masked]

sounds good.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Bason, Chris [mailto:[email-masked]]
>>Sent: Thursday, September 20, 2001 9:59 AM
>>To: [email-masked]
>>Subject: RE: Command Recovery
>>
>>
>>
>>We could avoid requiring client trid uniqueness by making
>>a status command that provided additional options for the
>>query. For example, if a registrar needed to perform a status
>>command for a specific client trid, they could also pass
>>in the operation that was being performed (e.g. CREATE, UPDATE,
>>etc.) and the date that the command was transmitted.
>>
>>The registry would then have 4 attributes to check for the
>>possible client trid being requested: registrar Id, operation, 
>>transaction date and client trid. If multiple rows were found 
>>for this combination then the status command would return a 
>>multi-row result set. It would then be up to the registrar to
>>process the result set returned to determine whether the transaction
>>they are looking for was processed.
>>
>
>This seems like a reasonable way to provide the functionality without
>significantly burdening either server or client.  Does anyone disagree?
>
><Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "Bason, Chris" <[email-masked]>, [email-masked]
Subject: RE: Command Recovery
Date: Thu, 20 Sep 2001 12:08:53 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Bason, Chris [mailto:[email-masked]]
>Sent: Thursday, September 20, 2001 9:59 AM
>To: [email-masked]
>Subject: RE: Command Recovery
>
>
>
>We could avoid requiring client trid uniqueness by making
>a status command that provided additional options for the
>query. For example, if a registrar needed to perform a status
>command for a specific client trid, they could also pass
>in the operation that was being performed (e.g. CREATE, UPDATE,
>etc.) and the date that the command was transmitted.
>
>The registry would then have 4 attributes to check for the
>possible client trid being requested: registrar Id, operation, 
>transaction date and client trid. If multiple rows were found 
>for this combination then the status command would return a 
>multi-row result set. It would then be up to the registrar to
>process the result set returned to determine whether the transaction
>they are looking for was processed.

This seems like a reasonable way to provide the functionality without
significantly burdening either server or client.  Does anyone disagree?

<Scott/>

Date: Thu, 20 Sep 2001 10:22:48 -0400
From: Daniel Manley <[email-masked]>
To: Thomas Corte <[email-masked]>
CC: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Subject: Re: Command Recovery
Sender: [email-masked]

Thomas,

I see your point but I think that it's not right to not enforce 
uniqueness and then throw an error if the queried identifier is not 
unique.  The server should probably enforce uniqueness right off the bat.

Dan

Thomas Corte wrote:

>Hello,
>
>On Wed, 19 Sep 2001, Hollenbeck, Scott wrote:
>
>>I think a bigger question involves uniqueness: does the server have to start
>>enforcing unique TRIDs for each client?  Across all clients?  As things are
>>written right now, the clTRIDs are basically just passed-through data that
>>the client can use to synchronize commands and responses, and the server
>>logs them as part of the larger transaction ID.  If the server doesn't
>>enforce uniqueness you can get multiple hits when trying to determine
>>status, which may not be helpful.  If the server does enforce uniqueness, it
>>becomes a bit more complex.
>>
>
>I think the server should not have to care about the uniqueness of client
>transaction ids; however, it should keep different 'transaction
>id namespaces' for all clients.
>If a client wants to benefit from the status command, it has to keep
>his own transaction ids unique, which is a simple task.
>The server may then simply report an error if it detects ambiguous
>transaction ids among a client's commands.
>
>Regards,
>_____________________________________________________________________
>     |       |
>     | knipp |                   Knipp  Medien und Kommunikation GmbH
>      -------                           Technologiepark
>                                        Martin-Schmeisser-Weg 9
>                                        D-44227 Dortmund
>     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
>     [email-masked]              Fax: +49-231-9703-200
>
>

From: "Bason, Chris" <[email-masked]>
To: [email-masked]
Subject: RE: Command Recovery
Date: Thu, 20 Sep 2001 09:59:01 -0400
Sender: [email-masked]

We could avoid requiring client trid uniqueness by making
a status command that provided additional options for the
query. For example, if a registrar needed to perform a status
command for a specific client trid, they could also pass
in the operation that was being performed (e.g. CREATE, UPDATE,
etc.) and the date that the command was transmitted.

The registry would then have 4 attributes to check for the
possible client trid being requested: registrar Id, operation, 
transaction date and client trid. If multiple rows were found 
for this combination then the status command would return a 
multi-row result set. It would then be up to the registrar to
process the result set returned to determine whether the transaction
they are looking for was processed.

Chris Bason

-----Original Message-----
From: Daniel Manley [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 12:40 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: Command Recovery

yuck, enforcing unique client trid's since the begining of operations 
could get relatively costly for each transform transaction, even if 
uniqueness is only required within a registrar.

How about enforcing uniqueness within a day?  The transaction info/check 
command could require a clTRID and a date to find the object.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Daniel Manley [mailto:[email-masked]]
>>Sent: Wednesday, September 19, 2001 11:31 AM
>>To: [email-masked]
>>Subject: Re: Command Recovery
>>
>
>
>>I guess option 1 seems like the most versatile and useful, so my 
>>preference is with 1.  Could client trids still be optional if you went 
>>ahead with number 1?  Does it even make sense to keep them optional in 
>>that case?
>>
>
>I think they can still be optional, you just lose the ability to check up
on
>one if it hasn't been provided.
>
>I think a bigger question involves uniqueness: does the server have to
start
>enforcing unique TRIDs for each client?  Across all clients?  As things are
>written right now, the clTRIDs are basically just passed-through data that
>the client can use to synchronize commands and responses, and the server
>logs them as part of the larger transaction ID.  If the server doesn't
>enforce uniqueness you can get multiple hits when trying to determine
>status, which may not be helpful.  If the server does enforce uniqueness,
it
>becomes a bit more complex.
>
><Scott/>
>

Date: Thu, 20 Sep 2001 15:45:56 +0200 (MESZ)
From: Thomas Corte <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Daniel Manley'" <[email-masked]>, <[email-masked]>
Subject: RE: Command Recovery
Sender: [email-masked]

Hello,

On Wed, 19 Sep 2001, Hollenbeck, Scott wrote:

> I think a bigger question involves uniqueness: does the server have to start
> enforcing unique TRIDs for each client?  Across all clients?  As things are
> written right now, the clTRIDs are basically just passed-through data that
> the client can use to synchronize commands and responses, and the server
> logs them as part of the larger transaction ID.  If the server doesn't
> enforce uniqueness you can get multiple hits when trying to determine
> status, which may not be helpful.  If the server does enforce uniqueness, it
> becomes a bit more complex.

I think the server should not have to care about the uniqueness of client
transaction ids; however, it should keep different 'transaction
id namespaces' for all clients.
If a client wants to benefit from the status command, it has to keep
his own transaction ids unique, which is a simple task.
The server may then simply report an error if it detects ambiguous
transaction ids among a client's commands.

Regards,
_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        D-44227 Dortmund
     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
     [email-masked]              Fax: +49-231-9703-200

Date: Wed, 19 Sep 2001 12:40:08 -0400
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Command Recovery
Sender: [email-masked]

yuck, enforcing unique client trid's since the begining of operations 
could get relatively costly for each transform transaction, even if 
uniqueness is only required within a registrar.

How about enforcing uniqueness within a day?  The transaction info/check 
command could require a clTRID and a date to find the object.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Daniel Manley [mailto:[email-masked]]
>>Sent: Wednesday, September 19, 2001 11:31 AM
>>To: [email-masked]
>>Subject: Re: Command Recovery
>>
>
>
>>I guess option 1 seems like the most versatile and useful, so my 
>>preference is with 1.  Could client trids still be optional if you went 
>>ahead with number 1?  Does it even make sense to keep them optional in 
>>that case?
>>
>
>I think they can still be optional, you just lose the ability to check up on
>one if it hasn't been provided.
>
>I think a bigger question involves uniqueness: does the server have to start
>enforcing unique TRIDs for each client?  Across all clients?  As things are
>written right now, the clTRIDs are basically just passed-through data that
>the client can use to synchronize commands and responses, and the server
>logs them as part of the larger transaction ID.  If the server doesn't
>enforce uniqueness you can get multiple hits when trying to determine
>status, which may not be helpful.  If the server does enforce uniqueness, it
>becomes a bit more complex.
>
><Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>, [email-masked]
Subject: RE: Command Recovery
Date: Wed, 19 Sep 2001 11:53:35 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Daniel Manley [mailto:[email-masked]]
>Sent: Wednesday, September 19, 2001 11:31 AM
>To: [email-masked]
>Subject: Re: Command Recovery

>I guess option 1 seems like the most versatile and useful, so my 
>preference is with 1.  Could client trids still be optional if you went 
>ahead with number 1?  Does it even make sense to keep them optional in 
>that case?

I think they can still be optional, you just lose the ability to check up on
one if it hasn't been provided.

I think a bigger question involves uniqueness: does the server have to start
enforcing unique TRIDs for each client?  Across all clients?  As things are
written right now, the clTRIDs are basically just passed-through data that
the client can use to synchronize commands and responses, and the server
logs them as part of the larger transaction ID.  If the server doesn't
enforce uniqueness you can get multiple hits when trying to determine
status, which may not be helpful.  If the server does enforce uniqueness, it
becomes a bit more complex.

<Scott/>

Date: Wed, 19 Sep 2001 11:30:39 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: Command Recovery
Sender: [email-masked]

>
>
>
>Ahh, OK, I see your point here.  I see two ways we might be able to address
>the issue:
>
>1. Add a status command that checks to see if a particular client-provided
>transaction identifier has been logged as part of a successful command.
>With client TRIDs being OPTIONAL [1] this won't work if the client doesn't
>provide a TRID, but it can help if they do.  Or,
>
>2. Add client TRID information to the <info> response for an object.  If we
>log the TRID of the last write operation (if one is provided), clients can
>do an <info> command, look at the client TRID, see if it's one they
>recognize, and react accordingly.
>
>Is one preferable over the other?  I kind of like the second option because
>it fits into what's documented right now.  Does anyone else have an opinion?
>
Option 1 would mean creating a transaction object and an info or check 
command for it?  Certainly option 1 holds more historical information. 
 But option 2 would be easier to implement...

I guess option 1 seems like the most versatile and useful, so my 
preference is with 1.  Could client trids still be optional if you went 
ahead with number 1?  Does it even make sense to keep them optional in 
that case?

Dan

Date: Wed, 19 Sep 2001 08:05:44 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: Command Recovery (was RE: interpretation of 'EPP idempotency')
Sender: [email-masked]

At 05:12 AM 9/19/2001, Hollenbeck, Scott wrote:
> >Well, a good OLTP system should also provide means for full recovery.
>
>No argument from me on that point.

As one would hope, the exchange on idempotency has been about "how", not 
"whether".

As I recall, Gray invented relational database methods, so a book on 
transaction processing, from him, ought to be more than adequate.

Given that:

1)      idempotency in transaction systems is something that has been 
around for a long time and is, presumably, well understood, and

2)      transaction systems are about exchanging things, just as protocols 
are about exchanging things, so the mechanisms for achieving idempotency 
should translate over to a protocol like EPP both easily and well.

therefore:

It should be straightforward to have EPP use a well-established technique 
from the transaction processing world, and the only debate should be about 
the tradeoffs among the well-established techniques for achieving idempotency.

Let me strongly encourage folks to cast the discussion strictly within that 
framework.

         -----

That was the primary point of this note.  Now...

Wandering into areas I know nothing about:

The protocol essences of indepotency would seem to be

a)      whether to add parameters, to achieve idempotency

         my own guess is that adding protocol features that are special for 
achieving idempotency is ok;

b)      whether to have special state changes.

         The latter means:  if an idempotent command previously succeeded 
at the server but is, for some reason, repeated by the client, should the 
server simply signal success or should it signal error.  Signalling success 
makes for a simpler state machine, since the client has no special 
processing to perform.  Hence the client would not be seeing, or 
participating in, "command recovery", but would merely be doing a command, 
the same as always.  The state machine in the server is essentially 
identical, except that rather than sending an error message it sends a success.

d/

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Command Recovery
Date: Wed, 19 Sep 2001 10:45:40 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Wednesday, September 19, 2001 10:41 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>Subject: Re: Command Recovery
>
>
>Sorry, I used the word 'preset' that did not expressed exactly what I
meant.
>Of course, the client has to specify the ID and there is no default. Unique
>keys of course. But here is another small disadvantage: The client has to
>select a unique key, whereas it would be much easier for the server to do
it
>as the server knows all used keys.

True, but the server doesn't know which key/identifier is one that the real
live person behind the contact may find easiest to use and remember, and we
do have a <check> facility in place to help determine what exists and what
doesn't.  Pluses and minuses both ways.  I know we've been over this issue
with ROIDs, handles, and the like, so I won't beat it any more.

>> 1. Add a status command that checks to see if a particular
client-provided
>> transaction identifier has been logged as part of a successful command.
>> With client TRIDs being OPTIONAL [1] this won't work if the client
doesn't
>> provide a TRID, but it can help if they do.  Or,
>> 
>> 2. Add client TRID information to the <info> response for an object.  If
we
>> log the TRID of the last write operation (if one is provided), clients
can
>> do an <info> command, look at the client TRID, see if it's one they
>> recognize, and react accordingly.
>> 
>> Is one preferable over the other?  I kind of like the second option
because
>> it fits into what's documented right now.  Does anyone else have an
opinion?
>>
>
>Solution 1 is a more generic approach, while solution 2 is obviously easier
to
>implement on server side. I discussed this with Thomas and we both think
that
>we would prefer solution 1.

OK, that's one position, thanks for weighing in.  I would _really_ like to
hear what others think as well since adding a new command is a fairly
significant step.

<Scott/>

Date: Wed, 19 Sep 2001 16:40:51 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: Command Recovery
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 
> >Yes, I do understand this. Nevertheless, to archive the idempotency
> property,
> >you add attributes to the commands that are not necessary. There is no
> >technical requirement to supply a preset ID to the registry for creating a
> new
> >contact. There is no technical requirement to supply the old expiration
> date
> >to renew a domain.
> 
> The contact <create> command requires an ID so that the contact can be
> uniquely identified, much like a domain or host name is used to uniquely
> identify a domain or host.  The ID isn't preset, it's requested at <create>
> time.
> 
> Earlier in this thread we heard about a problem that may arise when contacts
> aren't identified by a unique key.  If you're suggesting that unique
> identifiers/keys aren't needed to identify objects in a database, you've
> lost me.

Sorry, I used the word 'preset' that did not expressed exactly what I meant.
Of course, the client has to specify the ID and there is no default. Unique
keys of course. But here is another small disadvantage: The client has to
select a unique key, whereas it would be much easier for the server to do it
as the server knows all used keys.

> 
> > [...]
> >
> >Can you tell me what they should do in this situation?
> 
> Ahh, OK, I see your point here.  I see two ways we might be able to address
> the issue:
> 
> 1. Add a status command that checks to see if a particular client-provided
> transaction identifier has been logged as part of a successful command.
> With client TRIDs being OPTIONAL [1] this won't work if the client doesn't
> provide a TRID, but it can help if they do.  Or,
> 
> 2. Add client TRID information to the <info> response for an object.  If we
> log the TRID of the last write operation (if one is provided), clients can
> do an <info> command, look at the client TRID, see if it's one they
> recognize, and react accordingly.
> 
> Is one preferable over the other?  I kind of like the second option because
> it fits into what's documented right now.  Does anyone else have an opinion?
>

Solution 1 is a more generic approach, while solution 2 is obviously easier to
implement on server side. I discussed this with Thomas and we both think that
we would prefer solution 1.

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

Date: Wed, 19 Sep 2001 10:45:41 -0400
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "'Thomas Corte'" <[email-masked]>, [email-masked]
Subject: Re: interpretation of 'EPP idempotency'
Sender: [email-masked]

Hollenbeck, Scott wrote:

>I can't speak directly to .info's implementation, but it sounds a little kludgy as you describe it.
>
Yes, that does break the idempotency of the protocol, doesn't it?  I 
can't specifically speak for the reasons of using EPP for sunrise and 
landrush registrations of .info domains, but the side effects were 
great.  We were able to test our implementation of an EPP server and see 
its performance in a live environment under high loads.  It also helped 
us avoid the situation where the registrars had to develop two different 
interfaces to the .info registry (i.e. batch file processing and then 
real-time EPP).

I can't truly speak for Liberty/Afilias but I think their support team 
is trying to be as accomodating as possible, given that everyone is 
learning from this process.  If you encountered problems in registration 
of domains, you should give their tech support team a call and they 
might be able to check up on transactions for you to verify the number 
of times a domain has been submitted by your registrar.

I believe that they are closing the landrush queue by the end of this 
week, so this "un-idempotent" period will be over soon.

>
>As things are written in the specs, you should
>NOT be able to <create> an object more than once and receive a "success"
>response.  If you do a <create>, get back "success", do another <create>,
>and then get back another "success", the <create> command isn't idempotent.
>Executing the command multiple times doesn't produce the same state as
>executing the command once.
>
>EPP _is_ designed to handle special needs via the extension mechanism; it
>could be that .info was under time pressure to go ahead with an earlier
>version of the specs in which some of the extension possibilities weren't
>fully developed, or maybe the method as you described it was just seen as
>the easiest way to solve an immediate problem, even if it means <create> is
>no longer idempotent.  As you noted, when the command isn't idempotent there
>are issues to be dealt with -- and I'll be the first to admit that the
>protocol wasn't designed to deal with commands that aren't idempotent.
>
>>Why shouldn't EPP get an idempotency mechanism which is independent of
>>specific object or command semantics?
>>
>
>Because idempotency isn't a mechanism, it's a property -- it's an integral
>part of the way commands or transactions are structured to provide the
>property of being idempotent.
>
><Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>
Cc: [email-masked]
Subject: Command Recovery (was RE: interpretation of 'EPP idempotency')
Date: Wed, 19 Sep 2001 08:12:08 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Wednesday, September 19, 2001 4:39 AM
>To: Hollenbeck, Scott
>Cc: [email-masked]
>Subject: Re: interpretation of 'EPP idempotency'

>Yes, I do understand this. Nevertheless, to archive the idempotency
property,
>you add attributes to the commands that are not necessary. There is no
>technical requirement to supply a preset ID to the registry for creating a
new
>contact. There is no technical requirement to supply the old expiration
date
>to renew a domain.

The contact <create> command requires an ID so that the contact can be
uniquely identified, much like a domain or host name is used to uniquely
identify a domain or host.  The ID isn't preset, it's requested at <create>
time.

Earlier in this thread we heard about a problem that may arise when contacts
aren't identified by a unique key.  If you're suggesting that unique
identifiers/keys aren't needed to identify objects in a database, you've
lost me.

If you mean that the current expiration date doesn't need to be known to
renew a domain name, you're right.  However, not only does it help to make
the <renew> command idempotent, it helps to ensure that both client and
server have a consistent view of the object before and after processing the
command.  This isn't a bad thing.

>Well, a good OLTP system should also provide means for full recovery.

No argument from me on that point.

>Take the following example:
>
>It happens that a customer of registrars wants to register a domain.
>Unfortunately, he submits the domain twice. At the registrar, two different
>clients (in the view of the registry server) process these requests in
>parallel. Both send the corresponding domain create commands to the
registry.
>One of the commands succeeds, and the other fails, of course. But before
the
>responses are returned, a router in between crashes, killing the logical
>connections between the clients and the server.
>
>During recovery, whatever both clients will do, they both receive exactly
the
>same responses. They cannot determine whether their own request was
>successfully processed or not.
>
>Can you tell me what they should do in this situation?

Ahh, OK, I see your point here.  I see two ways we might be able to address
the issue:

1. Add a status command that checks to see if a particular client-provided
transaction identifier has been logged as part of a successful command.
With client TRIDs being OPTIONAL [1] this won't work if the client doesn't
provide a TRID, but it can help if they do.  Or,

2. Add client TRID information to the <info> response for an object.  If we
log the TRID of the last write operation (if one is provided), clients can
do an <info> command, look at the client TRID, see if it's one they
recognize, and react accordingly.

Is one preferable over the other?  I kind of like the second option because
it fits into what's documented right now.  Does anyone else have an opinion?

>Does software exist or is in development that deals with the problem we are
>discussing?

I'm not aware of anyone whose written anything to deal with the recovery
issue as you just described it, but I was specifically referring to software
that implements other service layers, like connection pooling or error
management.  I believe the Liberty RTK has features for both, and I know
that VeriSign is also writing such code.

<Scott/>

[1] Making client TRIDs OPTIONAL was discussed some time ago, and I don't
recall anyone objecting back then.  If anyone has an issue with it we really
ought to start a separate thread to reopen the issue.

Date: Wed, 19 Sep 2001 10:39:26 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: interpretation of 'EPP idempotency'
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 

> >your solution surely works, but, from a design perspective, this is IMHO a
> bad
> >solution. Each request has to take care for itself not to violate the
> >idempotency constraint. E.g. the contact create command e.g. requires to
> >specify a <contact:id> to solve the idempotency problem, but the renew
> command
> >requires something quite different, namely the current expiration date,
> which
> >does not make any sense for the semantics of the command itself.
> 
> Creation and renewal are fundamentally different operations, even at the
> database level.  Both, however, involve comparing the current state of an
> object to the desired state of an object and then doing something if it's
> possible to produce the desired state.  Given that different attributes
> define the state of an object and the operations that may be performed on
> the object, I don't see the problem with commands requiring different
> attributes to perform the needed state comparison.  In the case of renewal
> you're moving the current expiration date into the future, changing the
> state of the object as a result of a successful operation.  Using this
> attribute as an indicator of the current state prior to attempting to
> produce a new state is reasonable.  Likewise, using a different attribute (a
> unique identifier) to determine if an object can be created is also
> reasonable.

Yes, I do understand this. Nevertheless, to archive the idempotency property,
you add attributes to the commands that are not necessary. There is no
technical requirement to supply a preset ID to the registry for creating a new
contact. There is no technical requirement to supply the old expiration date
to renew a domain.

> 
> > [...]
> 
> I disagree.  If a client is unsure if any command was processed
> successfully, they can try it again.  Doing so is guaranteed to not have
> damaging results.  If they get back a "succeeded" response, they can update
> their own records and move on.  If they get back a "failed" response, they
> look into the third and fourth error code digits to determine the exact
> failure, and resynch/roll back/whatever accordingly.  If you're suggesting
> that a server shouldn't provide different types of error responses (and thus
> that a client shouldn't be expected to understand different failure modes),
> the alternative is to be more generic.  Software can be written to provide a
> layer of abstraction for a client that wants less detail, but at some point
> the detail needs to exist.
> 
> > [...]
>
> No, the responses are quite distinguishable.  In one case it may be
> "success", and in the other it may be "failure", and each is clearly
> identified by response code and a unique server-assigned transaction
> identifier.  This is as it should be because each response is tied directly
> to a very specific command, one of which succeeded and one of which failed.

There is a real misunderstanding here. Please see below.

> A good OLTP system should NOT provide a response to a command that describes
> the result of processing some other command.

Well, a good OLTP system should also provide means for full recovery.

> 
> > [...]

> The message received back shouldn't first be interpreted as "domain exists"
> in the case of a repeated domain create command failure -- the primary
> message is _"command failed"_, and the "domain exists" part is extra
> information that helps to explain why the command failed.  If the command
> fails, the client shouldn't create or keep it's own copy of the data.  If a
> response is lost, I think it's very reasonable for the client to issue a
> separate, atomic inquiry, and to ensure data consistency using the results
> of the query.  If they prefer to blindly repeat a command, that command MUST
> be treated as a distinct command in it's own right, it must succeed or fail
> in it's own right, and results reported must describe the success or failure
> of this isolated operation.  Doing otherwise is bad OLTP design.

In a single client model, i.e., a single client connects to the server, sends
commands and receives answers, this should work. But we have a lot of
registrars, and each registrar will maintain multiple connections to the
server. With the assumption that the clients of a single registrar work
independently, i.e., one client does not know what the other client does, your
model may fail. Take the following example:

It happens that a customer of registrars wants to register a domain.
Unfortunately, he submits the domain twice. At the registrar, two different
clients (in the view of the registry server) process these requests in
parallel. Both send the corresponding domain create commands to the registry.
One of the commands succeeds, and the other fails, of course. But before the
responses are returned, a router in between crashes, killing the logical
connections between the clients and the server.

During recovery, whatever both clients will do, they both receive exactly the
same responses. They cannot determine whether their own request was
successfully processed or not.

Can you tell me what they should do in this situation?

In the CORE SRS protocol, it is quite easy. Both clients submit a "status"
meta command with the client transaction ids of their create requests. This
command either tells them that their command has not been executed or returns
the results of their command. It neither violates the ACID properties you
mentioned. There is no requirement of deep analysis on the response behaviour
of the server on resubmitted commands.

> 
> >Instead of building upon idempotency constraints which affect the design of
> >each command, it would be better to have a separate layer that deals with
> >problems that appear in a client-server architecture. The way we do it in
> the
> >CORE SRS Protocol is one solution, it is quite simple and it works.
> 
> There's nothing stopping anyone from defining an additional processing layer
> to provide whatever feature you think is lacking.  Transport and security
> layers are already described, and folks are designing and implementing SDKs
> to provide additional abstract layers to deal with connection management,
> error handling, etc.

Does software exist or is in development that deals with the problem we are
discussing?

> 
> <Scott/>

regards,

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Thomas Corte'" <[email-masked]>
Cc: [email-masked]
Subject: RE: interpretation of 'EPP idempotency'
Date: Tue, 18 Sep 2001 21:48:18 -0400
Sender: [email-masked]

<Scott/> 

> -----Original Message-----
> From: Thomas Corte [mailto:[email-masked]]
> Sent: Tuesday, September 18, 2001 4:36 PM
> To: Hollenbeck, Scott
> Cc: 'Klaus Malorny'; [email-masked]
> Subject: RE: interpretation of 'EPP idempotency'

[snip]

> For example, the .info EPP server currently operates in a mode where
> multiple domains with the same name may be submitted using 
> EPP commands.
> If the same registrar resubmits a domain already submitted, 
> this succeeds
> and increases the entry count for this domain. Different 
> registrars may
> submit the same domain name, too. Furthermore, domain names submitted
> in this mode can not be inquired.
> Now, if I want to submit a domain name exactly once, what 
> should I do if
> for some reason I do not get the EPP server's response to my 
> submission? I
> can't inquire, I can't resubmit without risking a duplicate 
> entry, and I
> can't leave it alone if I want to be sure to have an entry in the
> repostory.
> 
> Admittedly, this is an exceptional situation. But all the 
> registries to
> come may have special cases like this, and I think EPP should 
> be able to
> handle it.

Thomas,

Now I see where your issues are coming from...

I can't speak directly to .info's implementation, but it sounds a little
kludgy as you describe it.  As things are written in the specs, you should
NOT be able to <create> an object more than once and receive a "success"
response.  If you do a <create>, get back "success", do another <create>,
and then get back another "success", the <create> command isn't idempotent.
Executing the command multiple times doesn't produce the same state as
executing the command once.

EPP _is_ designed to handle special needs via the extension mechanism; it
could be that .info was under time pressure to go ahead with an earlier
version of the specs in which some of the extension possibilities weren't
fully developed, or maybe the method as you described it was just seen as
the easiest way to solve an immediate problem, even if it means <create> is
no longer idempotent.  As you noted, when the command isn't idempotent there
are issues to be dealt with -- and I'll be the first to admit that the
protocol wasn't designed to deal with commands that aren't idempotent.

> Why shouldn't EPP get an idempotency mechanism which is independent of
> specific object or command semantics?

Because idempotency isn't a mechanism, it's a property -- it's an integral
part of the way commands or transactions are structured to provide the
property of being idempotent.

<Scott/>

Date: Tue, 18 Sep 2001 22:35:56 +0200 (MESZ)
From: Thomas Corte <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Klaus Malorny'" <[email-masked]>, <[email-masked]>
Subject: RE: interpretation of 'EPP idempotency'
Sender: [email-masked]

Hi Scott,

On Tue, 18 Sep 2001, Hollenbeck, Scott wrote:

> ... Using this
> attribute as an indicator of the current state prior to attempting to
> produce a new state is reasonable.  Likewise, using a different attribute (a
> unique identifier) to determine if an object can be created is also
> reasonable.

But this lack of a *universal* idempotency mechanism requires coming up
with an individual solution whenever new object types (besides
domains/contacts/hosts) should be handled over EPP.

Apart from that, the current solution fails when a registry needs to
weaken constraints for certain objects (temporarily or permanently).

For example, the .info EPP server currently operates in a mode where
multiple domains with the same name may be submitted using EPP commands.
If the same registrar resubmits a domain already submitted, this succeeds
and increases the entry count for this domain. Different registrars may
submit the same domain name, too. Furthermore, domain names submitted
in this mode can not be inquired.
Now, if I want to submit a domain name exactly once, what should I do if
for some reason I do not get the EPP server's response to my submission? I
can't inquire, I can't resubmit without risking a duplicate entry, and I
can't leave it alone if I want to be sure to have an entry in the
repostory.

Admittedly, this is an exceptional situation. But all the registries to
come may have special cases like this, and I think EPP should be able to
handle it.

Why shouldn't EPP get an idempotency mechanism which is independent of
specific object or command semantics?

Regards,

_____

Thomas Corte
<[email-masked]>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Klaus Malorny'" <[email-masked]>, [email-masked]
Subject: RE: interpretation of 'EPP idempotency'
Date: Tue, 18 Sep 2001 11:10:24 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Klaus Malorny [mailto:[email-masked]]
>Sent: Tuesday, September 18, 2001 9:31 AM
>To: Hollenbeck, Scott
>Cc: 'Thomas Corte'; Sheer El-Showk; [email-masked]
>Subject: Re: interpretation of 'EPP idempotency'
>
>
>"Hollenbeck, Scott" wrote:
>> 
>
>> No, this can't happen.  Every contact object has an associated identifier
>> (see the <contact:id> element described in sections 3.1.2 and 3.2.1 of
>> contact-02) that MUST be unique.  In the scenario you described, the
first
>> command will succeed.  The repeat will fail.
>
>
>Hi Scott,
>
>your solution surely works, but, from a design perspective, this is IMHO a
bad
>solution. Each request has to take care for itself not to violate the
>idempotency constraint. E.g. the contact create command e.g. requires to
>specify a <contact:id> to solve the idempotency problem, but the renew
command
>requires something quite different, namely the current expiration date,
which
>does not make any sense for the semantics of the command itself.

Creation and renewal are fundamentally different operations, even at the
database level.  Both, however, involve comparing the current state of an
object to the desired state of an object and then doing something if it's
possible to produce the desired state.  Given that different attributes
define the state of an object and the operations that may be performed on
the object, I don't see the problem with commands requiring different
attributes to perform the needed state comparison.  In the case of renewal
you're moving the current expiration date into the future, changing the
state of the object as a result of a successful operation.  Using this
attribute as an indicator of the current state prior to attempting to
produce a new state is reasonable.  Likewise, using a different attribute (a
unique identifier) to determine if an object can be created is also
reasonable.

>There is no
>uniform handling in the protocol. There is no chance to write software that
>deals with a communication interruption without knowing in detail what a
>specific request does and what the possible answers of the server are. This
is
>just a pain. There is no way to ask the server "did you perform the command
I
>sent to you?".

I disagree.  If a client is unsure if any command was processed
successfully, they can try it again.  Doing so is guaranteed to not have
damaging results.  If they get back a "succeeded" response, they can update
their own records and move on.  If they get back a "failed" response, they
look into the third and fourth error code digits to determine the exact
failure, and resynch/roll back/whatever accordingly.  If you're suggesting
that a server shouldn't provide different types of error responses (and thus
that a client shouldn't be expected to understand different failure modes),
the alternative is to be more generic.  Software can be written to provide a
layer of abstraction for a client that wants less detail, but at some point
the detail needs to exist.

>Even if the replay of a command does not change the state of
>the server, the client will get different answers. And these answers are
>indistinguishable.

No, the responses are quite distinguishable.  In one case it may be
"success", and in the other it may be "failure", and each is clearly
identified by response code and a unique server-assigned transaction
identifier.  This is as it should be because each response is tied directly
to a very specific command, one of which succeeded and one of which failed.
A good OLTP system should NOT provide a response to a command that describes
the result of processing some other command.

>What does a "domain exists" message really mean to the
>client? The client cannot determine whether the domain was created by
himself
>or by another instance running in parallel that accidentically wants to
create
>the very same domain? How should the client determine whether to create a
>mirror object in the own database? The only solution would be that the
client
>issues a inquire command and compares the data returned with the own data,
>e.g. compare all the contacts and hosts. Even in this case it is not
>guaranteed that the client's database becomes corrupted.

The message received back shouldn't first be interpreted as "domain exists"
in the case of a repeated domain create command failure -- the primary
message is _"command failed"_, and the "domain exists" part is extra
information that helps to explain why the command failed.  If the command
fails, the client shouldn't create or keep it's own copy of the data.  If a
response is lost, I think it's very reasonable for the client to issue a
separate, atomic inquiry, and to ensure data consistency using the results
of the query.  If they prefer to blindly repeat a command, that command MUST
be treated as a distinct command in it's own right, it must succeed or fail
in it's own right, and results reported must describe the success or failure
of this isolated operation.  Doing otherwise is bad OLTP design.

>Instead of building upon idempotency constraints which affect the design of
>each command, it would be better to have a separate layer that deals with
>problems that appear in a client-server architecture. The way we do it in
the
>CORE SRS Protocol is one solution, it is quite simple and it works.

There's nothing stopping anyone from defining an additional processing layer
to provide whatever feature you think is lacking.  Transport and security
layers are already described, and folks are designing and implementing SDKs
to provide additional abstract layers to deal with connection management,
error handling, etc.

<Scott/>

Date: Tue, 18 Sep 2001 15:38:46 +0200 (MESZ)
From: Thomas Corte <[email-masked]>
To: Daniel Manley <[email-masked]>
cc: [email-masked]
Subject: Re: interpretation of 'EPP idempotency'
Sender: [email-masked]

Hello Daniel,

On Tue, 18 Sep 2001, Daniel Manley wrote:

> Thomas,
> Would this example be pulled from the operation of the .info registry?
>  They are using a older version of the spec.  In that release, the
> contact create command contains no unique identifier from the registrar,
> so multiple requests for the same contact will create duplicated in the
> registry.  In the current version of the spec, the registrar must send a
> registry-unique identifier for the contact.  If the registrar uses a
> consistent method of generating a unique id (maybe a hash of the name
> and email address?), then multiple creates of the same contact would
> fail because the id won't be unique after the first create.

In fact, you are right - I deduced this example from Afilias'
current practice for contact creations and wasn't aware that they
use an old spec version.

However, I would highly appreciate a *uniform* solution for error
recovery, which is not present even in the most recent EPP draft (as
Klaus' recent mail pointed out).

Regards,
_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        D-44227 Dortmund
     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
     [email-masked]              Fax: +49-231-9703-200

Date: Tue, 18 Sep 2001 15:31:17 +0200
From: Klaus Malorny <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "'Thomas Corte'" <[email-masked]>, Sheer El-Showk <[email-masked]>, [email-masked]
Subject: Re: interpretation of 'EPP idempotency'
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 

> No, this can't happen.  Every contact object has an associated identifier
> (see the <contact:id> element described in sections 3.1.2 and 3.2.1 of
> contact-02) that MUST be unique.  In the scenario you described, the first
> command will succeed.  The repeat will fail.
> 
> <Scott/>

Hi Scott,

your solution surely works, but, from a design perspective, this is IMHO a bad
solution. Each request has to take care for itself not to violate the
idempotency constraint. E.g. the contact create command e.g. requires to
specify a <contact:id> to solve the idempotency problem, but the renew command
requires something quite different, namely the current expiration date, which
does not make any sense for the semantics of the command itself. There is no
uniform handling in the protocol. There is no chance to write software that
deals with a communication interruption without knowing in detail what a
specific request does and what the possible answers of the server are. This is
just a pain. There is no way to ask the server "did you perform the command I
sent to you?". Even if the replay of a command does not change the state of
the server, the client will get different answers. And these answers are
indistinguishable. What does a "domain exists" message really mean to the
client? The client cannot determine whether the domain was created by himself
or by another instance running in parallel that accidentically wants to create
the very same domain? How should the client determine whether to create a
mirror object in the own database? The only solution would be that the client
issues a inquire command and compares the data returned with the own data,
e.g. compare all the contacts and hosts. Even in this case it is not
guaranteed that the client's database becomes corrupted.

Instead of building upon idempotency constraints which affect the design of
each command, it would be better to have a separate layer that deals with
problems that appear in a client-server architecture. The way we do it in the
CORE SRS Protocol is one solution, it is quite simple and it works.

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

Date: Tue, 18 Sep 2001 08:46:38 -0400
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: interpretation of 'EPP idempotency'
Sender: [email-masked]

Thomas,
Would this example be pulled from the operation of the .info registry? 
 They are using a older version of the spec.  In that release, the 
contact create command contains no unique identifier from the registrar, 
so multiple requests for the same contact will create duplicated in the 
registry.  In the current version of the spec, the registrar must send a 
registry-unique identifier for the contact.  If the registrar uses a 
consistent method of generating a unique id (maybe a hash of the name 
and email address?), then multiple creates of the same contact would 
fail because the id won't be unique after the first create.

Dan

Thomas Corte wrote:

>Hello,
>
>On Tue, 18 Sep 2001, Hollenbeck, Scott wrote:
>
>>EPP operations are idempotent because repeated execution of any command has
>>the same effect on the state of the repository as successfully completing
>>the command once.  In some cases this happens because the command can't be
>>completed more than once -- you  can't, for example, create two instances of
>>the same domain name in the same repository.  In other cases, this happens
>>because the command is structured in such a way that repeated execution
>>doesn't produce a state change -- for example, updating an object twice (or
>>more) using the same command data yields an object that looks just like it
>>was updated once.  Idempotency for updates is provided by ensuring that
>>repeated updates produce the exact same object at the end of each update.
>>
>
>But consider the 'contact create' example from my previous e-mail:
>if I submit the same EPP command for contact creation multiple times,
>the EPP server has no chance to detect the repeat and therefore must
>create a fresh contact for each create command it sees, as there is
>no 'unique' constraint on contacts.
>So the repeated command results in repeated repository changes (multiple
>contact creations); this clearly violates the idempotency definition you
>quoted.
>
>However, I agree that returning the responses of previous commands
>would violate the rule of command isolation. Nevertheless, it would
>greatly facilitate client error handling.
>
>Regards,
>
>_____________________________________________________________________
>     |       |
>     | knipp |                   Knipp  Medien und Kommunikation GmbH
>      -------                           Technologiepark
>                                        Martin-Schmeisser-Weg 9
>                                        D-44227 Dortmund
>     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
>     [email-masked]              Fax: +49-231-9703-200
>
>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Object and Extension Identification Issue?
Date: Tue, 18 Sep 2001 08:29:01 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Hollenbeck, Scott [mailto:[email-masked]]
>Sent: Monday, September 17, 2001 8:01 AM
>To: [email-masked]'
>Subject: Object and Extension Identification Issue?
>
>
>So, is it a problem for implementers if the parser chokes when it can't
find
>a schema file?  If so, I can change things so that the <greeting> and
><login> describe services using the appropriate namespace URIs, like this:
>
><objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
>
>Discussion, please?

Perhaps I should have stated this differently -- I would like to change the
<greeting> and <login> elements to use a construct similar to what's shown
above unless someone really objects and can provide sound rationale for why
it shouldn't change.  I don't think it's a good idea to cause exceptions or
errors in normal processing, and the way things are currently specified
_does_ cause an error situation with at least one popular parser.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Thomas Corte'" <[email-masked]>
Cc: Sheer El-Showk <[email-masked]>, [email-masked]
Subject: RE: interpretation of 'EPP idempotency'
Date: Tue, 18 Sep 2001 08:16:48 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Thomas Corte [mailto:[email-masked]]
>Sent: Tuesday, September 18, 2001 8:07 AM
>To: Hollenbeck, Scott
>Cc: 'Thomas Corte'; Sheer El-Showk; [email-masked]
>Subject: RE: interpretation of 'EPP idempotency'
>
>
>
>Hello,
>
>On Tue, 18 Sep 2001, Hollenbeck, Scott wrote:
>
>> EPP operations are idempotent because repeated execution of any command
has
>> the same effect on the state of the repository as successfully completing
>> the command once.  In some cases this happens because the command can't
be
>> completed more than once -- you  can't, for example, create two instances
of
>> the same domain name in the same repository.  In other cases, this
happens
>> because the command is structured in such a way that repeated execution
>> doesn't produce a state change -- for example, updating an object twice
(or
>> more) using the same command data yields an object that looks just like
it
>> was updated once.  Idempotency for updates is provided by ensuring that
>> repeated updates produce the exact same object at the end of each update.
>
>But consider the 'contact create' example from my previous e-mail:
>if I submit the same EPP command for contact creation multiple times,
>the EPP server has no chance to detect the repeat and therefore must
>create a fresh contact for each create command it sees, as there is
>no 'unique' constraint on contacts.
>So the repeated command results in repeated repository changes (multiple
>contact creations); this clearly violates the idempotency definition you
>quoted.

No, this can't happen.  Every contact object has an associated identifier
(see the <contact:id> element described in sections 3.1.2 and 3.2.1 of
contact-02) that MUST be unique.  In the scenario you described, the first
command will succeed.  The repeat will fail.

<Scott/>

Date: Tue, 18 Sep 2001 14:07:23 +0200 (MESZ)
From: Thomas Corte <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Thomas Corte'" <[email-masked]>, Sheer El-Showk <[email-masked]>, <[email-masked]>
Subject: RE: interpretation of 'EPP idempotency'
Sender: [email-masked]

Hello,

On Tue, 18 Sep 2001, Hollenbeck, Scott wrote:

> EPP operations are idempotent because repeated execution of any command has
> the same effect on the state of the repository as successfully completing
> the command once.  In some cases this happens because the command can't be
> completed more than once -- you  can't, for example, create two instances of
> the same domain name in the same repository.  In other cases, this happens
> because the command is structured in such a way that repeated execution
> doesn't produce a state change -- for example, updating an object twice (or
> more) using the same command data yields an object that looks just like it
> was updated once.  Idempotency for updates is provided by ensuring that
> repeated updates produce the exact same object at the end of each update.

But consider the 'contact create' example from my previous e-mail:
if I submit the same EPP command for contact creation multiple times,
the EPP server has no chance to detect the repeat and therefore must
create a fresh contact for each create command it sees, as there is
no 'unique' constraint on contacts.
So the repeated command results in repeated repository changes (multiple
contact creations); this clearly violates the idempotency definition you
quoted.

However, I agree that returning the responses of previous commands
would violate the rule of command isolation. Nevertheless, it would
greatly facilitate client error handling.

Regards,

_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        D-44227 Dortmund
     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
     [email-masked]              Fax: +49-231-9703-200

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Thomas Corte'" <[email-masked]>, Sheer El-Showk <[email-masked]>
Cc: [email-masked]
Subject: RE: interpretation of 'EPP idempotency'
Date: Tue, 18 Sep 2001 07:45:47 -0400
Sender: [email-masked]

It's apparent from Thomas' note below and Sheer's note from yesterday that I
didn't explain the concept of idempotency well enough yesterday.  It really
has nothing to do with "don't repeat commands".

It may help to start with a definition.  One of the best I've seen can be
found in a book titled "Transaction Processing: Concepts and Techniques", by
Jim Gray and Andreas Reuter (ISBN 1-55860-190-2).  On page 136 it says that
"an operation is restartable or idempotent if redoing it is safe; that is,
if redoing it an arbitrary number of times is equivalent to doing it once".
Repeated execution results in no change of state.

There are also other properties, the ACID properties, to consider in a
transaction processing environment.  ACID is an acronym for Atomicity,
Consistency, Isolation, and Durability.  I'll leave the definition of these
terms to the reader.

Now to get back to Thomas' and Sheer's questions.

EPP operations are idempotent because repeated execution of any command has
the same effect on the state of the repository as successfully completing
the command once.  In some cases this happens because the command can't be
completed more than once -- you  can't, for example, create two instances of
the same domain name in the same repository.  In other cases, this happens
because the command is structured in such a way that repeated execution
doesn't produce a state change -- for example, updating an object twice (or
more) using the same command data yields an object that looks just like it
was updated once.  Idempotency for updates is provided by ensuring that
repeated updates produce the exact same object at the end of each update.

I hope the concept is more clear now.  As I said earlier, client identifiers
have nothing to do with idempotency -- it's the structure of the commands
themselves that provide idempotency.

Lastly, Thomas' suggestion to return the results of a previous command (say
a successful <add> command) in response to a repeat of the command is a
violation of the Isolation property.  In a good transaction processing
system, each transaction has to be treated as an atomic unit of work, and
responses have to be returned to describe the result of doing that unit of
work -- not to describe the result of doing some other unit of work
performed earlier.

<Scott/>

>-----Original Message-----
>From: Thomas Corte [mailto:[email-masked]]
>Sent: Tuesday, September 18, 2001 6:04 AM
>To: Sheer El-Showk
>Cc: Hollenbeck, Scott; [email-masked]
>Subject: RE: interpretation of 'EPP idempotency'
>
>
>
>Hello,
>
>On Mon, 17 Sep 2001, Sheer El-Showk wrote:
>
>> Both commands may fail but they should fail in different 
>ways.  If the
>> second command had a different client transaction identifer 
>then it should
>> never be processed.  We shouldn't return an "object already 
>exists" error
>> but some kind of "command already processed" error -- this 
>is an important
>> distinction that must be made.  You can't use object 
>uniquness to enforce
>> idempotency.  Idempotency has to apply to any write transaction --
>> insert/update/delete -- the first and last of these are by nature
>> idempotent, but update's aren't (and here update applies to transfer,
>> update, renew, etc...).  I thought that was what the client/server
>> transaction id was all about (see below).
>
>In my opinion, idempotency can not be forced without use of the client
>transaction id in some cases. For example, it is perfectly legal to
>create two contacts with the very same data (Name/Address etc.).
>If I resubmit a contact creation command due to a lost server response,
>the EPP server can not decide whether it should create a new contact
>(and return a new ROID) or not - idempotency can't be 
>guaranteed via the
>proposed 'object already exists' method.
>
>There is no real harm done in this case, because it would only 
>result in
>the creation of a redundant contact (which ROID is lost and 
>would never be
>used). But in principle, this violates protocol idempotency, 
>because the
>repeated command changes the repository while it shouldn't. 
>Only the usage
>of the client trid (or something similar) can solve the problem - using
>the same trid indicates 'the same command', using a different trid
>indicates 'a different command'. Of course, the client would 
>have to take
>care of the appropriate client trids.
>
>> I'm not sure why there's a problem here.  If the server garauntees
>> per-client uniqueness of the client transaction id (it has 
>to store them
>> anyway, it can just ensure they're unique), then command 
>idempotency is
>> ensured (so long as the client doesn't resend the same command with a
>> different client transaction id).  Basically if I try to 
>update a domain
>> and use a client transaction identifier, then if I never 
>receive a server
>> response I can resend the update as many times as I want 
>with the same
>> client transaction identifier, never worrying that the update may be
>> enacted twice (which would be bad if I'm adding a nameserver 
>for instance)
>> because the server will only accept the first successful 
>one.  The server
>> should send a response indicating that the command has already been
>> processed to all subsequent calls (that's why the object 
>already exists
>> one doesn't really work).
>
>I think that idempotency should give clients the possibility 
>for a uniform
>error handling. The client should *not* need to handle the
>outcome of repeated command itself. To shift this into a different
>'protocol layer', the described client trid method could be used.
>
>Moreover, IMHO the EPP server should just repeat the response 
>of the first
>command issue whenever it encounters a repeat (same client trid); then
>the clients would not have to worry about this issue at all.
>
>Regards,
>
>_____________________________________________________________________
>     |       |
>     | knipp |                   Knipp  Medien und Kommunikation GmbH
>      -------                           Technologiepark
>                                        Martin-Schmeisser-Weg 9
>                                        D-44227 Dortmund
>     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
>     [email-masked]              Fax: +49-231-9703-200
>
>
>

Date: Tue, 18 Sep 2001 12:04:15 +0200 (MESZ)
From: Thomas Corte <[email-masked]>
To: Sheer El-Showk <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Subject: RE: interpretation of 'EPP idempotency'
Sender: [email-masked]

Hello,

On Mon, 17 Sep 2001, Sheer El-Showk wrote:

> Both commands may fail but they should fail in different ways.  If the
> second command had a different client transaction identifer then it should
> never be processed.  We shouldn't return an "object already exists" error
> but some kind of "command already processed" error -- this is an important
> distinction that must be made.  You can't use object uniquness to enforce
> idempotency.  Idempotency has to apply to any write transaction --
> insert/update/delete -- the first and last of these are by nature
> idempotent, but update's aren't (and here update applies to transfer,
> update, renew, etc...).  I thought that was what the client/server
> transaction id was all about (see below).

In my opinion, idempotency can not be forced without use of the client
transaction id in some cases. For example, it is perfectly legal to
create two contacts with the very same data (Name/Address etc.).
If I resubmit a contact creation command due to a lost server response,
the EPP server can not decide whether it should create a new contact
(and return a new ROID) or not - idempotency can't be guaranteed via the
proposed 'object already exists' method.

There is no real harm done in this case, because it would only result in
the creation of a redundant contact (which ROID is lost and would never be
used). But in principle, this violates protocol idempotency, because the
repeated command changes the repository while it shouldn't. Only the usage
of the client trid (or something similar) can solve the problem - using
the same trid indicates 'the same command', using a different trid
indicates 'a different command'. Of course, the client would have to take
care of the appropriate client trids.

> I'm not sure why there's a problem here.  If the server garauntees
> per-client uniqueness of the client transaction id (it has to store them
> anyway, it can just ensure they're unique), then command idempotency is
> ensured (so long as the client doesn't resend the same command with a
> different client transaction id).  Basically if I try to update a domain
> and use a client transaction identifier, then if I never receive a server
> response I can resend the update as many times as I want with the same
> client transaction identifier, never worrying that the update may be
> enacted twice (which would be bad if I'm adding a nameserver for instance)
> because the server will only accept the first successful one.  The server
> should send a response indicating that the command has already been
> processed to all subsequent calls (that's why the object already exists
> one doesn't really work).

I think that idempotency should give clients the possibility for a uniform
error handling. The client should *not* need to handle the
outcome of repeated command itself. To shift this into a different
'protocol layer', the described client trid method could be used.

Moreover, IMHO the EPP server should just repeat the response of the first
command issue whenever it encounters a repeat (same client trid); then
the clients would not have to worry about this issue at all.

Regards,

_____________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
                                        D-44227 Dortmund
     Dipl.-Inform. Thomas Corte         Fon: +49-231-9703-0
     [email-masked]              Fax: +49-231-9703-200

Date: Mon, 17 Sep 2001 15:46:20 -0400 (EDT)
From: Sheer El-Showk <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Thomas Corte'" <[email-masked]>, <[email-masked]>
Subject: RE: interpretation of 'EPP idempotency'
Sender: [email-masked]

> Commands are also atomic and isolated, so it doesn't really matter if the
> server receives one command sent twice or a second command that contains a
> different client ID but the same "data".  Treating each command in isolation
> and assuming that the first succeeds, in either case the second command is
> an attempt to create an object that already exists.  In both cases, the
> second attempt fails because the object will already exist as a result of
> processing the first command successfully.

Both commands may fail but they should fail in different ways.  If the
second command had a different client transaction identifer then it should
never be processed.  We shouldn't return an "object already exists" error
but some kind of "command already processed" error -- this is an important
distinction that must be made.  You can't use object uniquness to enforce
idempotency.  Idempotency has to apply to any write transaction --
insert/update/delete -- the first and last of these are by nature
idempotent, but update's aren't (and here update applies to transfer,
update, renew, etc...).  I thought that was what the client/server
transaction id was all about (see below).

>
> If the client wants to create two separate contact objects with the same
> contact data, they must do so using separate and distinct contact
> identifiers.  An attempt to create a second object using an existing
> identifier must fail.
>
> The real issue is whether or not the object exists in the repository when
> the second attempt is made.  The second attempt succeeds if the object
> doesn't exist, and it fails if it does.
>
> >Can the client transaction id be used for this purpose?
>
> Not really, because the client ID is for a _client's_ tracking purposes, and
> the server can't be assured that every ID received from any particular
> client will be unique.

>From epp-04:

- An OPTIONAL <clTRID> (client transaction identifier) element that
  uniquely identifies the command to the client.

 - A <trID> (transaction identifier) element containing the transaction
  identifier assigned by the server to the command for which the
  response is being returned.  The transaction identifier is formed
  using the <clTRID> associated with the command if supplied by the
  client and a <svTRID> (server transaction identifier) that is assigned
  by and unique to the server.

  Transaction identifiers provide command-response synchronization
  integrity.  They SHOULD be logged, retained, and protected to ensure
  that both the client and the server have consistent temporal and state
  management records.

I'm not sure why there's a problem here.  If the server garauntees
per-client uniqueness of the client transaction id (it has to store them
anyway, it can just ensure they're unique), then command idempotency is
ensured (so long as the client doesn't resend the same command with a
different client transaction id).  Basically if I try to update a domain
and use a client transaction identifier, then if I never receive a server
response I can resend the update as many times as I want with the same
client transaction identifier, never worrying that the update may be
enacted twice (which would be bad if I'm adding a nameserver for instance)
because the server will only accept the first successful one.  The server
should send a response indicating that the command has already been
processed to all subsequent calls (that's why the object already exists
one doesn't really work).

Also, while this is being discussed I think the spec should make it clear
(I know the spec already uses a SHOULD not a MUST but it doesn't
distinguish between read-only and read-write commands) that client/server
transaction ids are not required (or even desirable) for
non-transactional commands such as check and info.  These are
read-only commands so command-response synchronization seems meaningless
to me.  Moreover, from a performance perspective, NSI has seen more than 1
billions checks in a month; logging each of these (ie logging the client
transaction id if provided) seems like a huge waste of resources.

>
> Does this help clear up the issue?  I can add text to the draft to help
> explain idempotency in more detail if that would help.

My undertanding is that the client/server transaction id were intended as
much for idempotency as for client audit tracking -- if not how is
idempotency to be ensured in updates?

Sheer

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: P3Pv1.xsd 
Date: Mon, 17 Sep 2001 13:58:54 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

>Give more time to think about things, are you now suggesting that the expiry
>element isn't useful, and that the entity element (which can include things
>like name and address of the policy publisher for those who might not
>understand the schema) is?  

Actually Scott what I wanted to do was put the xsd out as-is before going off
to Montevideo (ICANN) and vacation (now).

It will be a few days before I make it back to Portland.

The semantic nexus of P3P Spec WG discussion of expiry is the data collector
making a promise (of sorts) about the non-necessity of re-fetching and re-
evaluatinga policy. I don't think "expiry" is the sense of a temporal ID we
need, and we've already got <*Date>.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Thomas Corte'" <[email-masked]>, [email-masked]
Subject: RE: interpretation of 'EPP idempotency'
Date: Mon, 17 Sep 2001 13:28:42 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Thomas Corte [mailto:[email-masked]]
>Sent: Monday, September 17, 2001 12:45 PM
>To: [email-masked]
>Subject: interpretation of 'EPP idempotency'
>
>
>
>Hello,
>
>as stated in draft-ietf-provreg-epp-04.txt, the EPP features
>'protocol idempotency' to ensure 'the safety of retrying a command in
>cases of response delivery failure'.
>However, the implications of this feature is not specified in detail.
>
>My interpretation is that a command should cause changes in a registry's
>object repository only *once*. Repeating the very same command afterwards
>should only have effect on the repository if the EPP server has not yet
>processed it (e.g., because the first submission did not reach the server
>due to network problems). If it has been seen and processed already (e.g.,
>the command has only been re-submitted because the EPP server's response
>got lost on the way back to the client), then the command should *not* be
>executed again; instead, the response to the original command could simply
>be repeated by the EPP server.
>
>Question: Is the behaviour described above meant be the term 'idempotency'
>in the EPP draft?

Yes and no.  Yes in that the command should not be successfully executed a
second time (causing changes in a registry's object repository only once as
you noted), no in that the initial success response should not be returned a
second time -- the attempt to execute the same command a second time should
fail, resulting in an error return on the second attempt.

>If this is *not* the case, then I wonder about the correct interpretation
>and it's implications for, e.g., safe recovery from network problems.
>
>If this *is* the case, the next question would be how to distinguish 'the
>same command' from 'a different command with the same data', e.g. for
>creating two contact objects for the same person. In my opinion, the only
>way to accomplish this is the use of the 'client transaction id' provided
>by the EPP. If it was desired to create two separate contact objects with
>the same data, two different client transaction ids would have to be used.
>If a contact creation was only to be repeated because of a lost server
>answer, then the same client transaction id as in the initial submission
>would have to be given, giving the EPP server the opportunity to detect
>a repeated command.

Commands are also atomic and isolated, so it doesn't really matter if the
server receives one command sent twice or a second command that contains a
different client ID but the same "data".  Treating each command in isolation
and assuming that the first succeeds, in either case the second command is
an attempt to create an object that already exists.  In both cases, the
second attempt fails because the object will already exist as a result of
processing the first command successfully.

If the client wants to create two separate contact objects with the same
contact data, they must do so using separate and distinct contact
identifiers.  An attempt to create a second object using an existing
identifier must fail.

The real issue is whether or not the object exists in the repository when
the second attempt is made.  The second attempt succeeds if the object
doesn't exist, and it fails if it does.

>Can the client transaction id be used for this purpose?

Not really, because the client ID is for a _client's_ tracking purposes, and
the server can't be assured that every ID received from any particular
client will be unique.

Does this help clear up the issue?  I can add text to the draft to help
explain idempotency in more detail if that would help.

<Scott/>

Date: Mon, 17 Sep 2001 18:44:34 +0200 (MESZ)
From: Thomas Corte <[email-masked]>
To: [email-masked]
Subject: interpretation of 'EPP idempotency'
Sender: [email-masked]

Hello,

as stated in draft-ietf-provreg-epp-04.txt, the EPP features
'protocol idempotency' to ensure 'the safety of retrying a command in
cases of response delivery failure'.
However, the implications of this feature is not specified in detail.

My interpretation is that a command should cause changes in a registry's
object repository only *once*. Repeating the very same command afterwards
should only have effect on the repository if the EPP server has not yet
processed it (e.g., because the first submission did not reach the server
due to network problems). If it has been seen and processed already (e.g.,
the command has only been re-submitted because the EPP server's response
got lost on the way back to the client), then the command should *not* be
executed again; instead, the response to the original command could simply
be repeated by the EPP server.

Question: Is the behaviour described above meant be the term 'idempotency'
in the EPP draft?

If this is *not* the case, then I wonder about the correct interpretation
and it's implications for, e.g., safe recovery from network problems.

If this *is* the case, the next question would be how to distinguish 'the
same command' from 'a different command with the same data', e.g. for
creating two contact objects for the same person. In my opinion, the only
way to accomplish this is the use of the 'client transaction id' provided
by the EPP. If it was desired to create two separate contact objects with
the same data, two different client transaction ids would have to be used.
If a contact creation was only to be repeated because of a lost server
answer, then the same client transaction id as in the initial submission
would have to be given, giving the EPP server the opportunity to detect
a repeated command.

Can the client transaction id be used for this purpose?

Regards,

_____

Thomas Corte
<[email-masked]>

Date: Mon, 17 Sep 2001 11:32:43 -0400
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: EPP E.164 Number Mapping
Cc: [email-masked]
Sender: [email-masked]

Speaking as one of the chairs (to a curtailed addressee list):

  "Sounds like a good suggestion and a good answer." ;)

At 11:15 AM -0400 9/12/01, Richard Shockey wrote:
>At 05:10 PM 9/11/2001 -0400, Hollenbeck, Scott wrote:
>>Thanks for the comments, James, I'll work fixes into the next iteration.  I
>>doubt we should continue to talk about this draft on the provreg list,
>>though, since it's an individual submission and not a provreg work item.  If
>>either of the chairs disagree with me, I'm sure they'll speak up.
>
>I agree but you are more than welcome to discuss this on the ENUM list when
>ever you like.  I doubt we would consider this a work item _at this time_
>but this is exactly the kind of thoughtful technical document appropriate
>to discuss among the ENUM engineering community.

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

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

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: P3Pv1.xsd
Date: Mon, 17 Sep 2001 08:31:55 -0400
Sender: [email-masked]

Eric,

This differs slightly from the suggestion you sent to the list back in
April:

http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00108.html

Give more time to think about things, are you now suggesting that the expiry
element isn't useful, and that the entity element (which can include things
like name and address of the policy publisher for those who might not
understand the schema) is?

<Scott/>

>-----Original Message-----
>From: Eric Brunner-Williams in Portland Maine
>[mailto:[email-masked]]
>Sent: Monday, September 10, 2001 1:44 PM
>To: Hollenbeck, Scott
>Cc: [email-masked]'; [email-masked]
>Subject: P3Pv1.xsd
>
>
>Available at: http://www.s3.org/2000/12/P3Pv1.xsd, and here 
>for future list
>reference.
>
>As we look at data collectors using epp (registries, and 
>registrars, and even
>possibly resellers), there are several areas of the P3P 
>vocabulary that have
>different "fits" for our data collection policy purposes. In 
>top-to-bottom
>order these are (in my non-exhaustive estimation):
>	useful		not useful
>--------+---------------+----------------------------
>			POLICY-REFERENCES
>			POLICY-REF
>			EXPIRY
>			POLICIES
>			POLICY
>	ENTITY
>	ACCESS
>			DISPUTES-GROUP
>	STATEMENT
>	PURPOSE
>	RECIPIENT
>	RETENTION
>			DATA-GROUP
>			DATA
>	EXTENSION

[snip]

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Object and Extension Identification Issue?
Date: Mon, 17 Sep 2001 08:00:46 -0400
Sender: [email-masked]

While testing one of the schema changes that'll be done in the next version
of EPP I encountered something that may or may not be an issue for
implementers.  I'd like to ask if this is a problem, and if it is I can get
a fix into the next drafts.

Objects and extensions are described in a <greeting> and <login> command
like this:

<contact:svc
  xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
  xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
  contact-1.0.xsd"/>

The issue is that if the receiving end doesn't happen to have a copy of the
schema file on it's search path, at least one parser (Xerces-J) will throw
an exception because it can't find the file.  It's certainly likely that not
all clients will understand all of the objects or extensions supported by a
server, and the server may receive a <login> request containing a <svc>
element that it won't understand.

So, is it a problem for implementers if the parser chokes when it can't find
a schema file?  If so, I can change things so that the <greeting> and
<login> describe services using the appropriate namespace URIs, like this:

<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>

Discussion, please?

<Scott/>

Date: Thu, 13 Sep 2001 10:10:47 -0400
From: Daniel Manley <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Another To-Do Thought
Sender: [email-masked]

I would agree.

Dan

Hollenbeck, Scott wrote:

>Would anyone care if the <unspec> element tag was changed from "unspec" to
>"extension"?  I think "extension" makes the real meaning much easier to
>understand.
>
><Scott/>
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Another To-Do Thought
Date: Thu, 13 Sep 2001 08:21:15 -0400
Sender: [email-masked]

Would anyone care if the <unspec> element tag was changed from "unspec" to
"extension"?  I think "extension" makes the real meaning much easier to
understand.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Length of address fields (Re: EPP To-Do List)
Date: Thu, 13 Sep 2001 08:11:46 -0400
Sender: [email-masked]

>-----Original Message-----
>From: Hollenbeck, Scott [mailto:[email-masked]]
>Sent: Wednesday, September 12, 2001 1:41 PM
>To: [email-masked]'; [email-masked]
>Subject: RE: Length of address fields (Re: EPP To-Do List)
>
>
>Asbjorn,
>
>The 30-character limit is there because it conforms to an existing postal
>addressing standard for paper labels, which I don't have handy at the
>moment.  I tried to find some kind of international standard, and that was
>the best I found, though I'll admit it's not necessarily the most
>appropriate one to follow.

Now back at the office, I found the reference: ISO 11180:1993(E)

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Length of address fields (Re: EPP To-Do List)
Date: Wed, 12 Sep 2001 13:41:01 -0400
Sender: [email-masked]

Asbjorn,

The 30-character limit is there because it conforms to an existing postal
addressing standard for paper labels, which I don't have handy at the
moment.  I tried to find some kind of international standard, and that was
the best I found, though I'll admit it's not necessarily the most
appropriate one to follow.

This did come up on the list in the past, but as I look through the archives
I can't seem to find the appropriate message(s).  No matter, I don't mind
increasing the length, even doubling it, if that's what others think we
should do.

Any objections?  Would 64 (a power of two) characters allow some
implementation efficiencies?

<Scott/> 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, September 12, 2001 11:46 AM
> To: [email-masked]
> Subject: Length of address fields (Re: EPP To-Do List)
> 
> 
> Hi,
> 
> reading through contact-02 again, I noticed that the maximum length of
> postalLineType is 30. This means that no City names, 
> Registrant names, Street
> names, or Organization names can be longer than 30 characters.
> 
> I can't remember this being brought up before, but I strongly 
> believe that this
> is too short. I propose increasing it, maybe even doubling it to 60.
> 
> 
> Asbjorn Steira
> Global Name Registry

Date: 12 Sep 2001 15:46:02 -0000
From: [email-masked]
To: [email-masked]
Subject: Length of address fields (Re: EPP To-Do List)
Sender: [email-masked]

Hi,

reading through contact-02 again, I noticed that the maximum length of
postalLineType is 30. This means that no City names, Registrant names, Street
names, or Organization names can be longer than 30 characters.

I can't remember this being brought up before, but I strongly believe that this
is too short. I propose increasing it, maybe even doubling it to 60.

Asbjorn Steira
Global Name Registry

On Thu, 6 Sep 2001 09:09:38 -0400  "Hollenbeck, Scott" wrote:
[SNIP]
>7. Making the contact object street and postal code elements OPTIONAL:
>http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00034.html
>
[SNIP]
>
><Scott/>

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

Date: Wed, 12 Sep 2001 11:15:30 -0400
To: "Hollenbeck, Scott" <[email-masked]>, "'Yu, James'" <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: RE: EPP E.164 Number Mapping
Cc: "[email-masked]'" <[email-masked]>, [email-masked], Patrik  =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Sender: [email-masked]

At 05:10 PM 9/11/2001 -0400, Hollenbeck, Scott wrote:
>Thanks for the comments, James, I'll work fixes into the next iteration.  I
>doubt we should continue to talk about this draft on the provreg list,
>though, since it's an individual submission and not a provreg work item.  If
>either of the chairs disagree with me, I'm sure they'll speak up.

I agree but you are more than welcome to discuss this on the ENUM list when 
ever you like.  I doubt we would consider this a work item _at this time_ 
but this is exactly the kind of thoughtful technical document appropriate 
to discuss among the ENUM engineering community.

><Scott/>
>
> > -----Original Message-----
> > From: Yu, James [mailto:[email-masked]]
> > Sent: Tuesday, September 11, 2001 12:33 PM
> > To: 'Hollenbeck, Scott'
> > Cc: [email-masked]'
> > Subject: EPP E.164 Number Mapping
> >
> >
> > Scott,
> >
> > Two comments on the I-D:
> >
> > - Sections 3.1.1 and 3.1.2, first dashed item:
> >   <e164:name> is mentioned; however, <e164:dn> is used in the example.
> >
> > - Section 2.2.6 Replacement:
> >   Replacement field should be added.  There are cases when
> > the "flags" field
> > is empty, the Fully Qualified Domain Name in the replacement
> > field is used
> > to retrieve the NAPTR RRs next.
> >
> > James
> >

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice 571.434.5651 Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Yu, James'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: EPP E.164 Number Mapping
Date: Tue, 11 Sep 2001 17:10:30 -0400
Sender: [email-masked]

Thanks for the comments, James, I'll work fixes into the next iteration.  I
doubt we should continue to talk about this draft on the provreg list,
though, since it's an individual submission and not a provreg work item.  If
either of the chairs disagree with me, I'm sure they'll speak up.

<Scott/> 

> -----Original Message-----
> From: Yu, James [mailto:[email-masked]]
> Sent: Tuesday, September 11, 2001 12:33 PM
> To: 'Hollenbeck, Scott'
> Cc: [email-masked]'
> Subject: EPP E.164 Number Mapping
> 
> 
> Scott,
> 
> Two comments on the I-D:
> 
> - Sections 3.1.1 and 3.1.2, first dashed item:
>   <e164:name> is mentioned; however, <e164:dn> is used in the example.
> 
> - Section 2.2.6 Replacement:
>   Replacement field should be added.  There are cases when 
> the "flags" field
> is empty, the Fully Qualified Domain Name in the replacement 
> field is used
> to retrieve the NAPTR RRs next.
> 
> James  
> 

From: "Yu, James" <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: EPP E.164 Number Mapping
Date: Tue, 11 Sep 2001 11:33:16 -0500
Sender: [email-masked]

Scott,

Two comments on the I-D:

- Sections 3.1.1 and 3.1.2, first dashed item:
  <e164:name> is mentioned; however, <e164:dn> is used in the example.

- Section 2.2.6 Replacement:
  Replacement field should be added.  There are cases when the "flags" field
is empty, the Fully Qualified Domain Name in the replacement field is used
to retrieve the NAPTR RRs next.

James  

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: FW: [Epp-rtk-devel] requiring postal codes in contact info? 
Date: Mon, 10 Sep 2001 20:32:03 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> I much prefer not specifying any value at all if none is available.  I'm no
> expert in world-wide postal code formatting

Droll.

> and I'd prefer to not even try
> to suggest a default value that attempts to convey "none" out of fear of
> colliding with a representation that has some non-"none" meaning in some
> locale.

Sigh.

> Other optional contact elements can be left unspecified.  There's value in
> being consistent.

OK.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: FW: [Epp-rtk-devel] requiring postal codes in contact info? 
Date: Mon, 10 Sep 2001 18:48:15 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner-Williams in Portland Maine
> [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 5:39 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'; [email-masked]
> Subject: Re: FW: [Epp-rtk-devel] requiring postal codes in 
> contact info?
> 
> 
> 
> Scott,
> 
> Uniformity of postal format is limited.
> 
> pcType is a token.
> 
> "0" is a possible default value, as are quite a few other 
> NO-PCODE choices.

I much prefer not specifying any value at all if none is available.  I'm no
expert in world-wide postal code formatting, and I'd prefer to not even try
to suggest a default value that attempts to convey "none" out of fear of
colliding with a representation that has some non-"none" meaning in some
locale.

Other optional contact elements can be left unspecified.  There's value in
being consistent.

<Scott/>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: FW: [Epp-rtk-devel] requiring postal codes in contact info? 
Date: Mon, 10 Sep 2001 17:38:47 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

Uniformity of postal format is limited.

pcType is a token.

"0" is a possible default value, as are quite a few other NO-PCODE choices.

Eric

To: Klaus Malorny <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, Daniel Manley <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Questions about containers 
Date: Mon, 10 Sep 2001 17:14:50 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Of course you are right that containers live in the registry. Therefore I
> could try to hide the existance of containers. 

How would you go about revealing their existance?

>                                            ... Unfortunately, there exists a
> whois service. ...

The whois mailing lists, either whois:43, or the !43 list, exist for whois-ish
issues. I've no idea what you see as a connection, err, container.

> BTW, some more comments, independent from the discussion above:
> 
> * the response to <domain:info> request does not disclose whether an attribute
> (e.g. host or contact) is derived from its container or whether it has been
> inserted directly into the domain. Even a comparison with its container would
> not reveal this information. That's bad.

Thanks. I'll look into this.

> * There's a big chance that an update of a container may render objects that a
> directly or indirectly linked to that container void, e.g. a domain defines by
> itself 12 name servers, and the the user attempts to add two name servers to a
> container of it, thereby exceeding the limit of 13 name servers. Reparenting
> objects and containers also has a big probability to fail as suddenly some
> required contacts may be missing. Of course, such attempts should result into
> an error. But the document does not describe how this is done. I think the way
> this is reported must be defined clearly, and all objects that would become
> void must be reported.

Ditto.

> * although I see some benefits in the container model, I am realizing slowly
> that it does not help to overcome my "single registrant - multiple registrars"
> and "registrar - reseller" problems in any way.

Really? I think the second problem is addressed by containers.

Eric

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: P3Pv1.xsd
Date: Mon, 10 Sep 2001 13:43:37 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Available at: http://www.s3.org/2000/12/P3Pv1.xsd, and here for future list
reference.

As we look at data collectors using epp (registries, and registrars, and even
possibly resellers), there are several areas of the P3P vocabulary that have
different "fits" for our data collection policy purposes. In top-to-bottom
order these are (in my non-exhaustive estimation):
	useful		not useful
--------+---------------+----------------------------
			POLICY-REFERENCES
			POLICY-REF
			EXPIRY
			POLICIES
			POLICY
	ENTITY
	ACCESS
			DISPUTES-GROUP
	STATEMENT
	PURPOSE
	RECIPIENT
	RETENTION
			DATA-GROUP
			DATA
	EXTENSION

The legal entity may not be the apparent data collector (registry, etc., is
one of two or more operated by Operator Ink.), access can be EPP-constued as
registrant ability to modify data, statement groups purpose, recipient, and
retention, which are registry provisioning, and other announced purposes, to
the registry, and other announced recipients, for the registration period, 
and other announced retention periods. Extensions are of course MotherHood &
ApplePie in an XML world.

I'll comment on each of the "useful" ones subsequently.

Eric

<!DOCTYPE schema
  PUBLIC '-//W3C//DTD XMLSCHEMA 200010//EN'
  'http://www.w3.org/2000/10/XMLSchema.dtd' [
  <!ATTLIST schema 
    xmlns:p3p CDATA #FIXED 'http://www.w3.org/2000/12/P3Pv1'>
]>

<schema
  xmlns='http://www.w3.org/2000/10/XMLSchema'
  xmlns:p3p='http://www.w3.org/2000/12/P3Pv1'
  targetNamespace='http://www.w3.org/2000/12/P3Pv1'
  elementFormDefault='qualified'>

<!-- Basic P3P Data Type -->
 <simpleType name='yes_no'>
  <restriction base='string'>
   <enumeration value='yes'/>
   <enumeration value='no'/>
  </restriction>
 </simpleType>

<!-- *********** Policy Reference *********** -->
<!-- ************** META ************** -->
 <element name='META'>
  <complexType mixed='true'>
   <sequence minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3p:POLICY-REFERENCES'/>
    <element ref='p3p:POLICIES' minOccurs='0'/>
   </sequence>
  </complexType>
 </element>

<!-- ******* POLICY-REFERENCES ******** -->
 <element name='POLICY-REFERENCES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:POLICY-REF' minOccurs='0' maxOccurs='unbounded'/>
  </sequence>
  </complexType>
 </element>

 <element name='POLICY-REF'>
  <complexType>
   <sequence>
    <element name='INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
    <element name='EXCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
    <element name='COOKIE-INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='string'/>
    <element name='COOKIE-EXCLUDE'
             minOccurs='0' maxOccurs='unbounded' type='string'/>
    <element name='EMBEDDED-INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
    <element name='EMBEDDED-EXCLUDE'
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
    <element name='METHOD' 
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
   </sequence>
   <attribute name='about' type='uriReference' use='required'/>
  </complexType>
 </element>

<!-- ************* EXPIRY ************* -->
 <element name='EXPIRY'>
  <complexType>
   <attribute name='max-age' type='nonNegativeInteger' use='optional'/>
   <attribute name='date' type='string' use='optional'/>
  </complexType>
 </element>

<!-- ************ POLICIES ************ -->
 <element name='POLICIES'>
  <complexType>
   <sequence>
    <element ref='p3p:POLICY' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

<!-- **************** Policy **************** -->
<!-- ************* POLICY ************* -->
 <element name='POLICY'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:TEST' minOccurs='0'/>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:DATASCHEMA' minOccurs='0'/>
    <element ref='p3p:ENTITY'/>
    <element ref='p3p:ACCESS'/>
    <element ref='p3p:DISPUTES-GROUP' minOccurs='0'/>
    <element ref='p3p:STATEMENT' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='discuri' type='uriReference' use='required'/>
   <attribute name='opturi' type='uriReference' use='optional'/>
   <attribute name='name' type='ID' use='optional'/>
  </complexType>
 </element>

<!-- ************* TEST ************* -->
 <element name='TEST'>
  <complexType/>
 </element>

<!-- ************* ENTITY ************* -->
 <element name='ENTITY'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:DATA-GROUP'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

<!-- ************* ACCESS ************* -->
 <element name='ACCESS'>
  <complexType>
   <sequence>
    <choice>
     <element name='nonident' type='p3p:access-value'/>
     <element name='ident-contact' type='p3p:access-value'/>
     <element name='other-ident' type='p3p:access-value'/>
     <element name='contact-and-other' type='p3p:access-value'/>
     <element name='all' type='p3p:access-value'/>
     <element name='none' type='p3p:access-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='access-value'/>

<!-- ************ DISPUTES ************ -->
 <element name='DISPUTES-GROUP'>
  <complexType>
   <sequence>
    <element ref='p3p:DISPUTES' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <element name='DISPUTES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <choice minOccurs='0'>
     <sequence>
      <element ref='p3p:LONG-DESCRIPTION'/>
      <element ref='p3p:IMG' minOccurs='0'/>
      <element ref='p3p:REMEDIES' minOccurs='0'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
     <sequence>
      <element ref='p3p:IMG'/>
      <element ref='p3p:REMEDIES' minOccurs='0'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
     <sequence>
      <element ref='p3p:REMEDIES'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
    </choice>
   </sequence>
   <attribute name='resolution-type' use='required'>
    <simpleType>
     <restriction base='string'>
      <enumeration value='service'/>
      <enumeration value='independent'/>
      <enumeration value='court'/>
      <enumeration value='law'/>
     </restriction>
    </simpleType>
   </attribute>
   <attribute name='service' type='uriReference' use='required'/>
   <attribute name='verification' type='string' use='optional'/>
   <attribute name='short-description' type='string' use='optional'/>
  </complexType>
 </element>

<!-- ******** LONG-DESCRIPTION ******** -->
 <element name='LONG-DESCRIPTION'>
  <simpleType>
   <restriction base='string'/>
  </simpleType>
 </element>

<!-- ************** IMG *************** -->
 <element name='IMG'>
  <complexType>
   <attribute name='src' type='uriReference' use='required'/>
   <attribute name='width' type='nonNegativeInteger' use='optional'/>
   <attribute name='height' type='nonNegativeInteger' use='optional'/>
   <attribute name='alt' type='string' use='required'/>
  </complexType>
 </element>

<!-- ************ REMEDIES ************ -->
 <element name='REMEDIES'>
  <complexType>
   <sequence>
    <choice maxOccurs='unbounded'>
     <element name='correct' type='p3p:remedies-value'/>
     <element name='money' type='p3p:remedies-value'/>
     <element name='law' type='p3p:remedies-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='remedies-value'/>

<!-- *********** STATEMENT ************ -->
 <element name='STATEMENT'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element name='CONSEQUENCE' minOccurs='0' type='string'/>
    <element name='NON-IDENTIFIABLE' minOccurs='0'>
     <complexType/>
    </element>
    <element ref='p3p:PURPOSE'/>
    <element ref='p3p:RECIPIENT'/>
    <element ref='p3p:RETENTION'/>
    <element ref='p3p:DATA-GROUP' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='non-identifiable'/>

<!-- ************ PURPOSE ************* -->
 <element name='PURPOSE'>
  <complexType>
   <sequence>
    <choice maxOccurs='unbounded'>
     <element name='current' type='p3p:purpose-value'/>
     <element name='admin' type='p3p:purpose-value'/>
     <element name='develop' type='p3p:purpose-value'/>
     <element name='customization' type='p3p:purpose-value'/>
     <element name='tailoring' type='p3p:purpose-value'/>
     <element name='pseudo-analysis' type='p3p:purpose-value'/>
     <element name='pseudo-decision' type='p3p:purpose-value'/>
     <element name='individual-analysis' type='p3p:purpose-value'/>
     <element name='individual-decision' type='p3p:purpose-value'/>
     <element name='contact' type='p3p:purpose-value'/>
     <element name='historical' type='p3p:purpose-value'/>
     <element name='telemarketing' type='p3p:purpose-value'/>
     <element name='other-purpose'>
      <complexType mixed='true'>
       <attribute name='required' use='optional' type='p3p:required-value'/>
      </complexType>
     </element>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <simpleType name='required-value'>
  <restriction base='string'>
   <enumeration value='always'/>
   <enumeration value='opt-in'/>
   <enumeration value='opt-out'/>
  </restriction>
 </simpleType>

 <complexType name='purpose-value'>
  <attribute name='required' use='optional' type='p3p:required-value'/>
 </complexType>

<!-- *********** RECIPIENT ************ -->
 <element name='RECIPIENT'>
  <complexType>
   <sequence>
    <choice maxOccurs='unbounded'>
     <element name='ours'>
      <complexType>
       <sequence>
        <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/>
       </sequence>
      </complexType>
     </element>
     <element name='same' type='p3p:recipient-value'/>
     <element name='other-recipient' type='p3p:recipient-value'/>
     <element name='delivery' type='p3p:recipient-value'/>
     <element name='public' type='p3p:recipient-value'/>
     <element name='unrelated' type='p3p:recipient-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='recipient-value'>
  <sequence>
   <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/>
  </sequence>
  <attribute name='required' use='optional' type='p3p:required-value'/>
 </complexType>

 <element name='recipient-description'>
  <complexType mixed='true'/>
 </element>

<!-- *********** RETENTION ************ -->
 <element name='RETENTION'>
  <complexType>
   <sequence>
    <choice>
     <element name='no-retention' type='p3p:retention-value'/>
     <element name='stated-purpose' type='p3p:retention-value'/>
     <element name='legal-requirement' type='p3p:retention-value'/>
     <element name='indefinitely' type='p3p:retention-value'/>
     <element name='business-practices' type='p3p:retention-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='retention-value'/>

<!-- ************** DATA ************** -->
 <element name='DATA-GROUP'>
  <complexType>
   <sequence>
    <element ref='p3p:DATA' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='base' type='uriReference' 
              use='default' value='http://www.w3.org/TR/P3P/base'/>
  </complexType>
 </element>

 <element name='DATA'>
  <complexType mixed='true'>
   <sequence minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3p:CATEGORIES'/>
   </sequence>
   <attribute name='ref' type='uriReference' use='required'/>
   <attribute name='optional' use='default' value='no' type='p3p:yes_no'/>
  </complexType>
 </element>

<!-- ************** Data Schema ************* -->
<!-- *********** DATASCHEMA *********** -->
 <element name='DATASCHEMA'>
  <complexType>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3p:DATA-DEF'/>
    <element ref='p3p:DATA-STRUCT'/>
    <element ref='p3p:EXTENSION'/>
   </choice>
  </complexType>
 </element>

 <element name='DATA-DEF' type='p3p:data-def'/>
 <element name='DATA-STRUCT' type='p3p:data-def'/>

 <complexType name='data-def'>
  <sequence>
   <element ref='p3p:CATEGORIES' minOccurs='0'/>
   <element ref='p3p:LONG-DESCRIPTION' minOccurs='0'/>
  </sequence>
  <attribute name='name' type='ID' use='required'/>
  <attribute name='structref' type='uriReference' use='optional'/>
  <attribute name='short-description' type='string' use='optional'/>
 </complexType>

<!-- *********** CATEGORIES *********** -->
 <element name='CATEGORIES'>
  <complexType>
   <choice maxOccurs='unbounded'>
    <element name='physical' type='p3p:categories-value'/>
    <element name='online' type='p3p:categories-value'/>
    <element name='uniqueid' type='p3p:categories-value'/>
    <element name='purchase' type='p3p:categories-value'/>
    <element name='financial' type='p3p:categories-value'/>
    <element name='computer' type='p3p:categories-value'/>
    <element name='navigation' type='p3p:categories-value'/>
    <element name='interactive' type='p3p:categories-value'/>
    <element name='demographic' type='p3p:categories-value'/>
    <element name='content' type='p3p:categories-value'/>
    <element name='state' type='p3p:categories-value'/>
    <element name='political' type='p3p:categories-value'/>
    <element name='health' type='p3p:categories-value'/>
    <element name='preference' type='p3p:categories-value'/>
    <element name='government' type='p3p:categories-value'/>
    <element name='other-category' type='string'/>
   </choice>
  </complexType>
 </element>

 <complexType name='categories-value'/>

<!-- *********** EXTENSION ************ -->
 <element name='EXTENSION'>
  <complexType mixed='true'>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <any minOccurs='0' maxOccurs='unbounded' processContents='skip'/>
   </choice>
   <attribute name='optional' use='default' value='yes' type='p3p:yes_no'/>
  </complexType>
 </element>

</schema>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Data Collection Policy and Privacy Preferences
Date: Mon, 10 Sep 2001 08:46:32 -0400
Sender: [email-masked]

My "to-do" list from last week hasn't produced a whole lot of discussion
thus far, so let me start a thread on one topic that I'd like to explore a
bit further before doing a lot of writing: privacy preferences and how they
may relate to data collection policies.

We've discussed data collection policy issues fairly deeply.  The next
version of the EPP drafts will include an updated base protocol schema that
supports publication of a server's data collection policy.

We've also talked about a perceived need to include protocol features to
allow for exchange of a data originator's privacy preferences.  A common
comment has been that the issue is more complex than could be addressed by
tagging elements with a binary opt-in or opt-out flag, largely because such
a flag may not really convey enough information to be useful.

A thought: if we are now going to include publication of a server's data
collection policy, could a flag be used to note specific elements for which
a data originator wishes to specify selection of a policy option?  The
policy elements will specify server options (if any), and element attributes
can identify desired treatment of data in accordance with (or deviating
from) the published policy.  Addressing how a server might deal with
selections that deviate from the data collection policy is likely a matter
to be decided by server operators.

A more pointed question: do we have enough information to deal with this
now, or is the issue still too ambiguous to be addressed adequately?

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: I-D ACTION:draft-mrose-beep-transientid-00.txt
Date: Mon, 10 Sep 2001 07:21:10 -0400
Sender: [email-masked]

FYI; the I-D described below (thanks, Marshall!) addresses one of the BEEP
transport document comments we talked about last week.

<Scott/>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 10, 2001 6:54 AM
To: IETF-Announce; @loki.ietf.org
Subject: I-D ACTION:draft-mrose-beep-transientid-00.txt

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

	Title		: A Transient Prefix for Identifying Profiles under 
                          Development by the Working Groups of the IETF
	Author(s)	: M. Rose
	Filename	: draft-mrose-beep-transientid-00.txt
	Pages		: 5
	Date		: 07-Sep-01
	
As a part of their deliverables, working groups of the IETF may
develop BEEP profiles.  During the development process, it is
desirable to assign a transient identifier to each profile.  If the
profile is subsequently published as an RFC, then a permanent
identifier is subsequently assigned by the IANA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mrose-beep-transientid-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-mrose-beep-transientid-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-mrose-beep-transientid-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.

To: [email-masked], [email-masked]
Subject: Provreg minutes from London, repost
Date: Fri, 07 Sep 2001 13:54:25 +0200
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

Yesterday these were posted but they didn't make it to the mailinglists
due to the size of the two attachments (powerpoint presentation &
Microsoft word). It did however make it to the archives of the
mailing list
(http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00021.html),
including the attachments.  The link, IETF-51_provreg_Data_collection,
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00021.html/bin00001.bin,
is actually a microsoftword document, while XRP.ptt ,
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00021.html/bin00003.bin,
is indeed a powerpoint presentation.

The links with the % before it are small AppleDouble encoded
Macintosh files pointing to the two mentioned above.

Here I repost the minutes again, without the 2 attachments.

	jaap

(Message inbox:121)
  From: Edward Lewis <[email-masked]> 
  To: [email-masked], [email-masked] 
  Subject: Provreg minutes from London 

The official version...any further amendments will remain in the list archives.
------

Provreg Meeting Minutes
8-8-01, London England
Thanks to the primary note taker... Tom McGarry.

1. Agenda bashing - Ed Lewis
The "slides":
=============================================================================
Provisioning Registry Protocol WG (provreg)

Mailing list: [email-masked]
Charter: http://www.ietf.org/html.charters/provreg-charter.html
Web Page: http://www.cafax.se/ietf-provreg

Wednesday, August 08 at 1530-1730 (3:30pm-5:30pm)
=================================================

CHAIRS:	Jaap Akkerhuis <[email-masked]>
		Ed Lewis <[email-masked]>

AGENDA:

The usual: bashing (the agenda) & document/wg status.........15 minutes
     Minute taker (http://www.ietf.org/instructions/minutes.html)
     Blue Sheets

OPP draft, comparison w/EPP and GRRP (James).................25 minutes
     draft-jseng-provreg-opp-00.txt

Discussion on Data Collection Requirements (Scott)...........20 minutes
     draft-ietf-provreg-grrp-reqs-02.txt
     http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00002.html

EPP drafts, outside deadlines (Scott) ........................5 minutes
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-*-02.txt

XRP draft, comparison w/EPP and GRRP (Eric)..................25 minutes
     http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt

RIR comments on Provreg (Cathy, others?).....................15 minutes

Implementation-to-date commentary (?)........................15 minutes
     Discussion: comments are sought on the state of implementations of
     the proposals.  (Volunteers sought.)
                                                            ============
                                                               2 hours

Other Items that may creep into the agenda (but haven't been allotted time:

     The Definitions document
     draft-ietf-provreg-dn-defn-01.txt

>From the charter page:
Milestones

 Feb 2001 WG agreement on functional requirements for protocol
 Apr 2001 Initial specification of provreg protocol
 Jun 2001 Second draft specification
 Sep 2001 Submit draft for standards track

Internet-Drafts:
Domain Name and Related Definitions (17681 bytes)
Generic Registry-Registrar Protocol Requirements (46677 bytes)
Extensible Provisioning Protocol (111132 bytes)
Extensible Provisioning Protocol Contact Mapping (62792 bytes)
Extensible Provisioning Protocol Domain Name Mapping (62561 bytes)
Extensible Provisioning Protocol Host Mapping (43321 bytes)
Extensible Provisioning Protocol Transport Over TCP (12703 bytes)

NON-WG docs:
OPP: draft-jseng-provreg-opp-00.txt
XRP: draft-brunner-xrp-00.txt
=============================================================================
Review of milestones
EL - Original milestones were too aggressive.  Second draft was too loose.
New milestones are set to meet the groups needs, so we need to make sure to
keep pressing with the dates in mind.
Review of draft status
EL - Requirements draft is close to RFC, Core EPP draft has some proposed
changes, and other EPP extensions drafts have not yet been reviewed.
Two new non-wg docs; OPP and XRP

2. OPP Presentation - James Sang
Slides unavailable.
Mark Nottingham - Did you use existing XML protocol rather than develop a
new DTD?  JS - Other author needs to answer.  MN -I'll bring it to the list
Dave Crocker - What within EPP does not meet the needs of China?  JS - EPP
is a 2 entity protocol, does not support communications btwn other nodes
(r'ant-r'ar, r'ar-r'ar, etc.).  (Ask Dave.)
Eric Brunner-Williams - What kind of graph is OPP?  JS -
Rich Shockey - How will you maintain transactional intergrity btwn the
nodes?  JS - Every request is signed by each node.  RS - Do you prefer any
transport protocol?  JS - No we are transport agnostic.
Dave Crocker - Clarification
Jordyn Buchanan - Can't EPP meet your needs if we added the requirements
for signatures btwn nodes?
Mark Nottingham Guy - Do you plan on using XML schema rather than new DTD
Dan Manly - How do you make sure proper security is in each node?
Rich Shockey - What application would require coordination btwn four nodes?
Jordyn Buchanan - R'ant need to authenticate with a r'y, discussed on the
list and has been desire of some ccTLDs.  JS - Multiple tiered phone
companies.  Scott Hollenbeck response to JB, current EPP draft doesn't
provide this capability, but there's o reason why it couldn't be updated or
extension added.

EL - Should the WG accept the document?
Dave Crocker - Not good to have two protocol documents but we could try to
address the needs met in the document by integrating it into EPP documents.

EL - It may be best for JS to get the document where he wants it before
accepting it.
George Ballotsky - Process is too rushed to get a good protocol.
EL - We'll take the question to the list.
(Document has since been withdrawn from consideration.)

4.	Data Collection Policy Requirement - Scott Hollenbeck
Slides attached.
Dave Crocker - You can keep the rqmt knowing that it can't be resolved
right now.
Dan Manly - There can be a preference hierarchy.
Eric Brunner-Williams - I've addressed the suggested changes on the list.
R'ys need to distinguish btwn social and technical data.  Policy
announcement by R'ys is the problem that needs to be solved.  P3P is used
as a starting point because it exists, there's no suggestion that Provreg
follow P3P policies or procedures.  SH - What is the information that you
want presented?  EBW - Current policy at the time of the transaction.
Jordyn Buchanan - There are instances where r'ants may want to pick a
policy but r'y contracts dictate what the r'y does.  EBW - R'ars or r'ys
may request data that is above and beyond what is necessary and not
required by the contracts.
Dan Manly - R'ys can provide that information on their websites or by other
means.
Jordyn Buchanan - It would be good to hear from non-gTLDs.
Dave Crocker - It's an important issue and should be addressed, but it's
notin the critical path of ths group.  EBW - It's been done so this is not
a
Paul Kane - There are rqmts similar to this in some countries.
EL - Straw pole; As is - a few, Changed - none, Deferred - more than as is.
Dan Manly - Does deferring this break any laws in any countries?  Many
Yes's shouted out, no No's.

5.	EPP Status - Scott Hollenbeck

6.	XRP - Eric Brunner-Williams
Slides attached.
Jordyn Buchanan - I prefer distinct documents.  Is it possible to separate
BEEP from Push?  EBW - Yes.
Scott Hollenbeck - I support separate documents.  Push has some problems if
client is off.  Messages need to Que.  I support including it and moving
forward.
Dan Manly - Experience shows that r'ars are having a problem understanding
EPP.  Further extensions would only add to the confusion.
Dave Crocker - I originally thought that polling was the est solution
however the internet comunty has ot had allot of experience with
transaction models the more I learn about it the more I believe that there
are great performance benefits in push.
Jordyn Buchanan - There should be consistency with the event model.
Bruce Tonkin - R'ants should expect different models from different r'ys.
I support push as an option of the core protocol.
Rich Shockey - I support Bruce and disagree with Jordyn.  Let's not
preclude features that support other (non-domain name) r'ys.
Scott Hollenbeck - Push could create push-storms to the r'ars.
Dave Crocker - Queing problems could be solved out of the protocol such and
email.

7.  Notes on GRRP/EPP from an RIR - Cathy Murphy (ARIN)

Presentation Notes:
===========================================================================
ProvReg

Focus: How the drafts might or might not relate to the RIR's (mostly not)

* Current drafts are okay, but definitely domain centric, focus
  on relationships that can be seen with domain registrations

Commonalities:
- do registration of some kind of information at a basic level
- some user scenarios are the same (many ISPs act as re-sellers/brokers)
- similar registration of nameserver information (in-addr.arpa)
- similar registration of contact information (Whois)

Differences/Issues:

*1* fundamental difference: any "rights" of usage of domain name
    ends up with the registrant versus IP control is fundamentally
    hierarchical
    - end-user subject to upstream, whether an ISP, NIR, LIR or RIR
    - IP "transfer" is a top-down, not bottom-up, process
    - IP registration request is not for a specific, identifiable object
      like a domain name; rather, it describes an amount (/18), which they
      might or might not receive.

*2* Most domain registrations (GRRP) tend to be session-oriented, versus
    RIR registration process, which is longer and may extend over several
    days/weeks.
    - EPP 2.0 "All EPP commands are atomic and idempotent."
    - XRP 2.3 "XRP supports four major types of services  ...
      Each of these services is atomic in nature and identifies a logical
      transaction. Each of the requests is idempotent, either succeeding
      completely or failing completely and producing predictable results
      in case of repeated execution."
    - GRRP provides near immediate registration; RIR has a whole analysis
      review period (comparable to if domain registry were required to
      perform research for the other "IP", i.e., intellectual property
      and/or trademark research, and confirm application information)

    * first contact with RIR is more like an application, not registration

*3* RIRs don't have the volume
    - IP and AS Regs: 500 p/wk (max)
    - SWIP's/3000-5000K per day
    - transfers: 2 week minimum to process
    - routing registrations -- "IRR" -- different beast for ARIN; couldn't
      tell you the numbers

*4* Contact info is "technical" versus "social"

SUMMARY:

Suggest that ProvReg change Generic Registry Registrar Protocol (GRRP) to
Generic Domain Registry Registrar Protocol (GDRRP); save GRRP term if and
until there is a core protocol that does speak to registration objects
other than domain names.
===========================================================================
Domains have rights of the name holder.  IP addresses are different.
RIRs don't get requests for specific names.
EPP protocols are connection oriented.  IP addresses are not.  The
processes take longer.
RIRs do not receive the volume of requests DNS R'ys do.  500 in a week
would be allot.
Contact information is technical in nature and not social, there's a rqmt
to disclose it.
EPP needs to go a layer below.
EBW - Are you aware of anyone selling contact databases?  CM - No.
Mark Kosters - There is social data collected by RIRs.  They will need to
be concerned about privacy rights.
EBW - Can GRRP be saved or would you prefer it not be intended for RIRs?
CM - I prefer that it get changed to met RIR needs, but I understand that
there is a time issue here with the gTLD r'ys.
Scott Hollenbeck - Draft and WG goals are specific to domain names.  We
could have a new rqmts for RIRs.
Greg Someone Telnic - Some registries may be required

8.  XRP vs EPP
Poll - WG preference is to hammer the two into one protocol.
Scott Hollenbeck - The XRP extensions can be included as extensions.
Patrick Falstrom - Is it a problem if there were two models?  JB - If we
try it will fail.
Dave Crocker - Worry about long term and high performance.
Scott Hollenbeck - There is interest in writing an SCTP transport.  I don't
want to be forced to implement BEEP right now even though I believe it is a
good thing n the long term.
Mark Nottingham - W3C is also addressing this issue.

Content-Disposition: attachment; filename="IETF-51_provreg_Data_Collection"

Content-Disposition: attachment; filename="XRP.ppt"

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

From: "Damaraju, Ayesha" <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: EPP To-Do List
Date: Thu, 6 Sep 2001 14:01:07 -0500 
Sender: [email-masked]

Scott,

If it is not noted already.
THe info response of contact and domain have authinfo as
required field in the schemas.....text says it is optional.

-A

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 9:10 AM
To: [email-masked]'
Subject: EPP To-Do List

Before I get started with edits to produce the next version of the EPP
drafts, I wanted to let everyone know what's been queued for incorporation.
I'd also like to ensure that everyone is OK with the changes, and I'll note
places where I'd like to see more discussion before changing anything.
Here's the list, sorted by date posted to the mailing list:

1. Addition of data collection policy elements based on suggestions received
from Eric Brunner-Williams:
http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00108.html

2. Minor typos noted by Asbjorn Steira:
http://www.cafax.se/ietf-provreg/maillist/2001-06/msg00059.html

3. More typos noted by Dan Manley:
http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00012.html

4. Fix text to note that XML Schema requires extended date-time forms:
http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00015.html

5. Changing all of the schema and namespace URIs to use a new format
suggested in the Mealling XML registry I-D:
http://www1.ietf.org/mail-archive/ietf-announce/Current/msg14309.html

6. Additional text to provide a note to implementers that command-response
interactions may require some smarts if not exchanged on a strict
one-for-one basis:
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00033.html

7. Making the contact object street and postal code elements OPTIONAL:
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00034.html

There were also a few ideas suggested by Sheer El-Showk for which I'm not
sure we came to a conclusion.  First was a suggestion to add host transfer
features:
http://www.cafax.se/ietf-provreg/maillist/2001-08/msg00003.html

The ensuing discussion focused more on glue generation than host transfers.
We've certainly covered this topic before, and my read of the debate is that
there are still more people who feel that independent host transfers should
not be supported.  If that's still the case, I intend to leave things as-is.

Second was a suggestion to add an option to the domain <info> command to
allow a client to select if subordinate host and/or delegated name server
data is returned in the <info> response:
http://www.cafax.se/ietf-provreg/maillist/2001-08/msg00006.html

No one objected, so I'm inclined to add features to support this.

We've talked about push vs. poll, and seemed to reach consensus (I say
seemed because I haven't seen any straw poll results) on providing an
optional way to do pushing.  I don't think the current extension mechanisms
suffice, because we're not talking about extending either a type of object
or a currently defined command or response.  However, I think we can add a
new <any> hook at the <command>, <response>, <greeting>, <hello> level so
that a new type of element (maybe an <alert> or something similar) can be
defined in an extension document.  This means that we open up the
possibility of all sorts of extensions, but it seems like the only real way
to provide for server-initiated message pushing.  Thoughts?  If you'd like
to comment, please start a new thread.

I've had multiple private conversations with people who believe we need to
provide support to identify explicit registrant consent for use of personal
data, such as contact data.  The suggestions I've received boil down to
adding an attribute to some of the contact elements to note explicit
"opt-in" desire.  I'd like to talk about this further, so if anyone is
inclined to support or flame the idea, let's start a new thread for this
topic, too.

Lastly, I'd like to make the Acknowledgement sections more explicit so that
folks who've made material contributions (new features, suggested fixes,
etc.) are explicitly named.  please contact me directly if you've
participated in that way and you wish to have your name listed.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP To-Do List
Date: Thu, 6 Sep 2001 09:09:38 -0400 
Sender: [email-masked]

Before I get started with edits to produce the next version of the EPP
drafts, I wanted to let everyone know what's been queued for incorporation.
I'd also like to ensure that everyone is OK with the changes, and I'll note
places where I'd like to see more discussion before changing anything.
Here's the list, sorted by date posted to the mailing list:

1. Addition of data collection policy elements based on suggestions received
from Eric Brunner-Williams:
http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00108.html

2. Minor typos noted by Asbjorn Steira:
http://www.cafax.se/ietf-provreg/maillist/2001-06/msg00059.html

3. More typos noted by Dan Manley:
http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00012.html

4. Fix text to note that XML Schema requires extended date-time forms:
http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00015.html

5. Changing all of the schema and namespace URIs to use a new format
suggested in the Mealling XML registry I-D:
http://www1.ietf.org/mail-archive/ietf-announce/Current/msg14309.html

6. Additional text to provide a note to implementers that command-response
interactions may require some smarts if not exchanged on a strict
one-for-one basis:
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00033.html

7. Making the contact object street and postal code elements OPTIONAL:
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00034.html

There were also a few ideas suggested by Sheer El-Showk for which I'm not
sure we came to a conclusion.  First was a suggestion to add host transfer
features:
http://www.cafax.se/ietf-provreg/maillist/2001-08/msg00003.html

The ensuing discussion focused more on glue generation than host transfers.
We've certainly covered this topic before, and my read of the debate is that
there are still more people who feel that independent host transfers should
not be supported.  If that's still the case, I intend to leave things as-is.

Second was a suggestion to add an option to the domain <info> command to
allow a client to select if subordinate host and/or delegated name server
data is returned in the <info> response:
http://www.cafax.se/ietf-provreg/maillist/2001-08/msg00006.html

No one objected, so I'm inclined to add features to support this.

We've talked about push vs. poll, and seemed to reach consensus (I say
seemed because I haven't seen any straw poll results) on providing an
optional way to do pushing.  I don't think the current extension mechanisms
suffice, because we're not talking about extending either a type of object
or a currently defined command or response.  However, I think we can add a
new <any> hook at the <command>, <response>, <greeting>, <hello> level so
that a new type of element (maybe an <alert> or something similar) can be
defined in an extension document.  This means that we open up the
possibility of all sorts of extensions, but it seems like the only real way
to provide for server-initiated message pushing.  Thoughts?  If you'd like
to comment, please start a new thread.

I've had multiple private conversations with people who believe we need to
provide support to identify explicit registrant consent for use of personal
data, such as contact data.  The suggestions I've received boil down to
adding an attribute to some of the contact elements to note explicit
"opt-in" desire.  I'd like to talk about this further, so if anyone is
inclined to support or flame the idea, let's start a new thread for this
topic, too.

Lastly, I'd like to make the Acknowledgement sections more explicit so that
folks who've made material contributions (new features, suggested fixes,
etc.) are explicitly named.  please contact me directly if you've
participated in that way and you wish to have your name listed.

<Scott/>

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: [Epp-rtk-devel] requiring postal codes in contact info?
Date: Thu, 6 Sep 2001 08:34:11 -0400 
Sender: [email-masked]

Here's another EPP modification suggestion that folks doing the Liberty RTK
have thought about.  The end result was a suggestion that both postal code
and street elements should be optional.

http://www.geocrawler.com/archives/3/12114/2001/8/50/6355635/

<Scott/>

-----Original Message-----
From: Dipankar Ghosh [mailto:[email-masked]]
Sent: Tuesday, August 07, 2001 5:30 PM
To: [email-masked]
Subject: [Epp-rtk-devel] requiring postal codes in contact info?

Hi,

I have an issue with the specification of the Contact information, and
specifically with the requirement that the PostalCode field be mandatory:

 - <complexType name="addrType">
  - <sequence>
  <element name="street" type="contact:localeType" maxOccurs="3" />
  <element name="city" type="contact:localeType" />
  <element name="sp" type="contact:localeType" minOccurs="0" />
  <element name="pc" type="contact:pcType" />
  <element name="cc" type="contact:ccType" />
  </sequence>
  </complexType>

This is primarily because I do not believe postal codes exist for all
countries. At least there are no standards I have found till now that
indicate the availability of postal codes for the 100+ ISO recognized
countries.

Any thoughts?

Dipankar
Bulkregister.com

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: EPP Command Question
Date: Thu, 6 Sep 2001 08:13:58 -0400 
Sender: [email-masked]

FYI.  I received the private message included below back in August, and I
intend to address the comment in the next version of the EPP specifications.
I'm sending the suggestion to the list so it gets properly archived.

The genesis of the suggested text involved a request to add clarifying text
so that implementers understood that they may have to deal with commands and
responses that don't get exchanged in a tidy one-for-one fashion.

<Scott/>

-----Original Message-----
From: John Immordino [mailto:[email-masked]]
Sent: Monday, August 06, 2001 3:04 PM
To: Hollenbeck, Scott
Subject: RE: EPP Command Question

For the EPP spec:

"Be sure you consider the mechanics of command-response 
synchronization if you implement an EPP client that supports 
asynchronous command-response exchanges.  If you implement an
EPP server, you must support asynchronous command-response 
exchanges unless you can guarantee synchronous-only clients."

For the TCP spec (append to Section 3):

"An EPP client may support asynchronous command-response
exchanges.  In this case, a server may receive, in the 
course of a single read operation, data that includes
multiple client commands or command fragments.  The server 
must scan the incoming client data, extract and execute 
properly formed commands as described above, and carry over 
any remaining data as a prefix to the data received in the
next read operation.

I'll keep my day job...:-)

- John

Date: Thu, 06 Sep 2001 11:16:25 +0200
From: Klaus Malorny <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
CC: Daniel Manley <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Questions about containers
Sender: [email-masked]

Eric Brunner-Williams in Portland Maine wrote:
> 
> containers "live" in the registry. end-users don't set them up and instantiate
> them in the registry, as they've no access except as mediated by a registrar.

Hi Eric,

Of course you are right that containers live in the registry. Therefore I
could try to hide the existance of containers. Unfortunately, there exists a
whois service. I assume that it would also give detailed information about the
containers the domains are linked to (otherwise, this service wouldn't be very
practical for professionals). But this service is also available to end-users
and resellers, so I as a registrar/reseller (and not the registry) have the
pain to educate them. And even much more trivial concepts are sometimes quite
hard to explain to the masses.

BTW, some more comments, independent from the discussion above:

* the response to <domain:info> request does not disclose whether an attribute
(e.g. host or contact) is derived from its container or whether it has been
inserted directly into the domain. Even a comparison with its container would
not reveal this information. That's bad.

* There's a big chance that an update of a container may render objects that a
directly or indirectly linked to that container void, e.g. a domain defines by
itself 12 name servers, and the the user attempts to add two name servers to a
container of it, thereby exceeding the limit of 13 name servers. Reparenting
objects and containers also has a big probability to fail as suddenly some
required contacts may be missing. Of course, such attempts should result into
an error. But the document does not describe how this is done. I think the way
this is reported must be defined clearly, and all objects that would become
void must be reported.

* although I see some benefits in the container model, I am realizing slowly
that it does not help to overcome my "single registrant - multiple registrars"
and "registrar - reseller" problems in any way.

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeißer-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

Date: Wed, 05 Sep 2001 15:00:18 -0700
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Questions about containers 
Cc: <[email-masked]>
Sender: [email-masked]

Let me test out my own perspective on containers:

Computer science loves deferred binding.  Although it can have serious 
efficiency problems, it benefits from allowing accuracy and dynamic 
"configuration".

Within the registration world, there is need to support vastly different 
business models, as wells as what might be called different registration 
models.

Therefore we want to be very, very careful about the relationships that we 
require -- as opposed to allow -- between data objects.

The container construct is a way of decoupling one or more dependencies 
that the standard might otherwise have to impose.

d/

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

To: Daniel Manley <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Questions about containers 
Date: Wed, 05 Sep 2001 16:26:01 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Yes, I am FULLY aware of the relationship between a registrant, its 

Good.

> registrar and the registry.  But you still didn't answer Klaus' question 
> (and mine too) in regards to the trade-off of complexity vs. benefits 
> with containers.  I don't see many registrars offering more than a 

Speculation, neh? 

> single container for a registrant to bundle all their domains together 
> -- with possibly those containers inheriting from a single master 
> "we-host-em" container (borrowing from your example).

So ... don't use them. It isn't as if we're talking manditory-to-implement.

Eric

Date: Wed, 05 Sep 2001 16:12:22 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Questions about containers
Sender: [email-masked]

Eric Brunner-Williams in Portland Maine wrote:

>
>>2) Do containers and their relations to other objects preclude the 
>>associations defined in the EPP domain draft?
>>
>
>Uh, what?
>
The domain draft written by Scott says that contacts and hosts get 
associated directly to individual domain objects through the create and 
update command.  The container spec presents implicit associations 
between objects in the same container or with other objects in 
super-containers.  So does that mean that the direct associations 
through the domain object are invalid or ignored?

>
>>4) Can you explain the difference between child objects and linked 
>>objects?  That wasn't completely clear to me.
>>
>
>Suppose container object FOO looks alot like Registrar X's basic we-host-em
>package. It has a root and some child objects, looking a bit like the ASCII
>art in the draft. Each sale of the basic w-h-e package need only link to a
>container object (this).
>
Sorry, it's still not quite clear.  The linking operation is done by 
making a registrant's typical "w-h-e" container as a child object of the 
registrar's master container (which would contain default nameservers 
and contacts)?  This tells me that linking is just another term for 
making into a child object.  I probably still don't have this right. 
 Feel free to explain further.

>
>
>>5) The container delete description specifies that the authInfo must 
>>be provided.  This isn't right is it?
>>
>
>Why not?
>
Hey, it just looked unusual because no other objects require auth info 
to delete them.  I thought that it might have been a copy/paste typo 
from the container create section.

>
>
>>6) In container delete, what is the difference between using the none 
>>and the break option?  Taking no action on related objects implicitly 
>>breaks their association with the deleted container right?
>>
>>7) The following paragraph states that a container should not be 
>>deleted if it is associated with other known objects.  Is that really 
>>saying that containers can't be delete as long as they have a parent?  
>>The way it is worded there, I couldn't help but try to extrapolate a 
>>meaning with the previous option element (none, delete, break).  But 
>>maybe that's just the way I interpreted it.
>>
>
>Let's take these two or three up when I get back from travel (business first,
>then pleasure, I think). After the 18th. Ayesha and Ning can answer better in
>any case.
>
If Ayesha or Ning can answer in your place, that would be great.  Thanks.

>
>>9) Referring to the diagram example in the draft, if a registrar 
>>associated a domain to Container 3, would that domain have Host 1 
>>(from Container 1) and Host 2 in it's DNS records?
>>
>
>Yup. Unless there was some ordering or maximal rule associated with object
>containers of type Container_3, e.g., only one (bizzare) NS (host).
>
Ok.  How about a follow-up question to this:  so doing an info on a 
domain would lists all of its nameservers and contacts, including all 
inherited ones? (which kinda goes back to question numbered 2 above).

>
>
>>I might forward more questions as I study the document a little more.
>>
>
>And I'm sure the document will improve as it is critically read by eyes
>other than its authors. 
>
>Eric
>

Date: Wed, 05 Sep 2001 16:03:49 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Questions about containers
Sender: [email-masked]

Eric Brunner-Williams in Portland Maine wrote:

>containers "live" in the registry. end-users don't set them up and instantiate
>them in the registry, as they've no access except as mediated by a registrar.
>
Yes, I am FULLY aware of the relationship between a registrant, its 
registrar and the registry.  But you still didn't answer Klaus' question 
(and mine too) in regards to the trade-off of complexity vs. benefits 
with containers.  I don't see many registrars offering more than a 
single container for a registrant to bundle all their domains together 
-- with possibly those containers inheriting from a single master 
"we-host-em" container (borrowing from your example).

To: Daniel Manley <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Questions about containers 
Date: Wed, 05 Sep 2001 14:45:40 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

containers "live" in the registry. end-users don't set them up and instantiate
them in the registry, as they've no access except as mediated by a registrar.

To: Edward Lewis <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: BEEP Transport 
Date: Wed, 05 Sep 2001 14:31:11 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

That counts as an "asked" in my book. Thanks.

Date: Wed, 5 Sep 2001 14:29:18 -0400
To: Eric Brunner <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: BEEP Transport
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 4:28 PM -0400 9/4/01, Eric Brunner wrote:
>Note to the chairs, I take the transfer from "individual" to "working group"
>seriously. If asked I will edit the working group drafts which I was a
>co-author. If the chairs and/or the WG designate someone(s) else, I'll give
>them the nroff sources.

Generally, the person doing the typing doesn't change unless that person 1)
no longer wants to work on the document or 2) does not respond to WG
consensus.

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

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

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

Date: Wed, 05 Sep 2001 14:35:16 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Questions about containers
Sender: [email-masked]

Eric Brunner-Williams in Portland Maine wrote:

>>Do the benefits you expect from containers legitimate the enormous amount of
>>complexity they add to a registry, registrar or reseller system (as they
>>introduce hierarchical/recursive data structures)? Do you think the normal
>>end-user is able to understand this concept?
>>
>
>My idea of a normal end-user is a registrar with a tool kit and a manual of
>recommended practice to a) make his or her life easier, and b) make him or
>her and the upstream registry as efficient as possible. Greater ROI. Who is
>your idea of the normal end-user?
>
I understand his point of view, Eric.  How should registrars represent 
containers and hierarchies to their customers (and their own customer, 
in turn) while still keeping it simple and easy to use?  The hierarchy 
is cool, but it could get really messy if a basic end-user gets confused 
and sets up a couple of containers with all kinds of hosts, contacts and 
domains and doesn't understand why the domain isn't resolving or why the 
whois output doesn't show all the contacts they set up (or more than 
they expected).

Taking full advantage of contains also could mean "significant" 
development on both the registry's and registrar's part (and further 
users down the pipe) to make sure data structures are setup right and 
that the structures are easy to manipulate by the registrant.

To: Klaus Malorny <[email-masked]>
cc: Daniel Manley <[email-masked]>, "[email-masked]'" <[email-masked]>, Eric Brunner <[email-masked]>, [email-masked]
Subject: Re: Questions about containers 
Date: Tue, 08 May 2001 00:01:16 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> Do the benefits you expect from containers legitimate the enormous amount of
> complexity they add to a registry, registrar or reseller system (as they
> introduce hierarchical/recursive data structures)? Do you think the normal
> end-user is able to understand this concept?

My idea of a normal end-user is a registrar with a tool kit and a manual of
recommended practice to a) make his or her life easier, and b) make him or
her and the upstream registry as efficient as possible. Greater ROI. Who is
your idea of the normal end-user?

> Still, the spec is confusing to me. Some terms are used in a way that is
> unfamilar to _me_, the initial ASCII art graphic suggests something different
> than what is described in the text. But I will try harder.

I wish I had an editor that could keep the semantics, or even the syntax, of
different sections of text, and sections of text and non-text, consistent and
help keep me from being confused. I used Rose during the CPExchange work, but
we don't use propriatary tools or non-ASCII formats in IETF memos.

> As far as I understand the document, the graph should look more like:

>       +-------------+   .
>       |   "linked"  |....
>       | Object ???? |--------+
>       +-------------+        |   +--------------+
>                              +==>| addl. objects|
>                                  +--------------+

Nope. The linked object points at a container object. I'll try harder myself
the next go-round.

Eric

To: Daniel Manley <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, Eric Brunner <[email-masked]>, [email-masked]
Subject: Re: Questions about containers 
Date: Mon, 07 May 2001 23:54:02 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

I don't think I ever saw a prior original.

: I'm reposting this since I haven't seen a reply yet.  If I missed the 
: reply somehow, could someone please send it to me or repost it to the list?

> 1) XRP is mentioned twice without introduction.  Is this leftover from 
> the XRP drafts?

Yup. Typos-R-me.

> 2) Do containers and their relations to other objects preclude the 
> associations defined in the EPP domain draft?

Uh, what?

> 3) The registrant -- that is simply a contact right.  I might have 
> missed it but I don't think it explicitly says that.

Yup.

> 4) Can you explain the difference between child objects and linked 
> objects?  That wasn't completely clear to me.

Suppose container object FOO looks alot like Registrar X's basic we-host-em
package. It has a root and some child objects, looking a bit like the ASCII
art in the draft. Each sale of the basic w-h-e package need only link to a
container object (this).

> 5) The container delete description specifies that the authInfo must 
> be provided.  This isn't right is it?

Why not?

> 6) In container delete, what is the difference between using the none 
> and the break option?  Taking no action on related objects implicitly 
> breaks their association with the deleted container right?
>
> 7) The following paragraph states that a container should not be 
> deleted if it is associated with other known objects.  Is that really 
> saying that containers can't be delete as long as they have a parent?  
> The way it is worded there, I couldn't help but try to extrapolate a 
> meaning with the previous option element (none, delete, break).  But 
> maybe that's just the way I interpreted it.
>

Let's take these two or three up when I get back from travel (business first,
then pleasure, I think). After the 18th. Ayesha and Ning can answer better in
any case.

> 8) How does a registrar know which templates exist in the registry? 
> Will that information be provided out-of-band in contracts or notices 
> from the registry?

Since templates are registry-private instances of canned policy, that is
as good a way as any.

> 9) Referring to the diagram example in the draft, if a registrar 
> associated a domain to Container 3, would that domain have Host 1 
> (from Container 1) and Host 2 in it's DNS records?

Yup. Unless there was some ordering or maximal rule associated with object
containers of type Container_3, e.g., only one (bizzare) NS (host).

> I might forward more questions as I study the document a little more.

And I'm sure the document will improve as it is critically read by eyes
other than its authors. 

Eric

Date: Wed, 5 Sep 2001 11:53:38 -0400
To: [email-masked], [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Provreg minutes from London
Cc: [email-masked], [email-masked]
Sender: [email-masked]

--============_-1212417275==_============
Content-Type: text/plain; charset="us-ascii"

The official version...any further amendments will remain in the list archives.
------

Provreg Meeting Minutes
8-8-01, London England
Thanks to the primary note taker... Tom McGarry.

1. Agenda bashing - Ed Lewis
The "slides":
=============================================================================
Provisioning Registry Protocol WG (provreg)

Mailing list: [email-masked]
Charter: http://www.ietf.org/html.charters/provreg-charter.html
Web Page: http://www.cafax.se/ietf-provreg

Wednesday, August 08 at 1530-1730 (3:30pm-5:30pm)
=================================================

CHAIRS:	Jaap Akkerhuis <[email-masked]>
		Ed Lewis <[email-masked]>

AGENDA:

The usual: bashing (the agenda) & document/wg status.........15 minutes
     Minute taker (http://www.ietf.org/instructions/minutes.html)
     Blue Sheets

OPP draft, comparison w/EPP and GRRP (James).................25 minutes
     draft-jseng-provreg-opp-00.txt

Discussion on Data Collection Requirements (Scott)...........20 minutes
     draft-ietf-provreg-grrp-reqs-02.txt
     http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00002.html

EPP drafts, outside deadlines (Scott) ........................5 minutes
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
     http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-*-02.txt

XRP draft, comparison w/EPP and GRRP (Eric)..................25 minutes
     http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt

RIR comments on Provreg (Cathy, others?).....................15 minutes

Implementation-to-date commentary (?)........................15 minutes
     Discussion: comments are sought on the state of implementations of
     the proposals.  (Volunteers sought.)
                                                            ============
                                                               2 hours

Other Items that may creep into the agenda (but haven't been allotted time:

     The Definitions document
     draft-ietf-provreg-dn-defn-01.txt

>From the charter page:
Milestones

 Feb 2001 WG agreement on functional requirements for protocol
 Apr 2001 Initial specification of provreg protocol
 Jun 2001 Second draft specification
 Sep 2001 Submit draft for standards track

Internet-Drafts:
Domain Name and Related Definitions (17681 bytes)
Generic Registry-Registrar Protocol Requirements (46677 bytes)
Extensible Provisioning Protocol (111132 bytes)
Extensible Provisioning Protocol Contact Mapping (62792 bytes)
Extensible Provisioning Protocol Domain Name Mapping (62561 bytes)
Extensible Provisioning Protocol Host Mapping (43321 bytes)
Extensible Provisioning Protocol Transport Over TCP (12703 bytes)

NON-WG docs:
OPP: draft-jseng-provreg-opp-00.txt
XRP: draft-brunner-xrp-00.txt
=============================================================================
Review of milestones
EL - Original milestones were too aggressive.  Second draft was too loose.
New milestones are set to meet the groups needs, so we need to make sure to
keep pressing with the dates in mind.
Review of draft status
EL - Requirements draft is close to RFC, Core EPP draft has some proposed
changes, and other EPP extensions drafts have not yet been reviewed.
Two new non-wg docs; OPP and XRP

2. OPP Presentation - James Sang
Slides unavailable.
Mark Nottingham - Did you use existing XML protocol rather than develop a
new DTD?  JS - Other author needs to answer.  MN -I'll bring it to the list
Dave Crocker - What within EPP does not meet the needs of China?  JS - EPP
is a 2 entity protocol, does not support communications btwn other nodes
(r'ant-r'ar, r'ar-r'ar, etc.).  (Ask Dave.)
Eric Brunner-Williams - What kind of graph is OPP?  JS -
Rich Shockey - How will you maintain transactional intergrity btwn the
nodes?  JS - Every request is signed by each node.  RS - Do you prefer any
transport protocol?  JS - No we are transport agnostic.
Dave Crocker - Clarification
Jordyn Buchanan - Can't EPP meet your needs if we added the requirements
for signatures btwn nodes?
Mark Nottingham Guy - Do you plan on using XML schema rather than new DTD
Dan Manly - How do you make sure proper security is in each node?
Rich Shockey - What application would require coordination btwn four nodes?
Jordyn Buchanan - R'ant need to authenticate with a r'y, discussed on the
list and has been desire of some ccTLDs.  JS - Multiple tiered phone
companies.  Scott Hollenbeck response to JB, current EPP draft doesn't
provide this capability, but there's o reason why it couldn't be updated or
extension added.

EL - Should the WG accept the document?
Dave Crocker - Not good to have two protocol documents but we could try to
address the needs met in the document by integrating it into EPP documents.

EL - It may be best for JS to get the document where he wants it before
accepting it.
George Ballotsky - Process is too rushed to get a good protocol.
EL - We'll take the question to the list.
(Document has since been withdrawn from consideration.)

4.	Data Collection Policy Requirement - Scott Hollenbeck
Slides attached.
Dave Crocker - You can keep the rqmt knowing that it can't be resolved
right now.
Dan Manly - There can be a preference hierarchy.
Eric Brunner-Williams - I've addressed the suggested changes on the list.
R'ys need to distinguish btwn social and technical data.  Policy
announcement by R'ys is the problem that needs to be solved.  P3P is used
as a starting point because it exists, there's no suggestion that Provreg
follow P3P policies or procedures.  SH - What is the information that you
want presented?  EBW - Current policy at the time of the transaction.
Jordyn Buchanan - There are instances where r'ants may want to pick a
policy but r'y contracts dictate what the r'y does.  EBW - R'ars or r'ys
may request data that is above and beyond what is necessary and not
required by the contracts.
Dan Manly - R'ys can provide that information on their websites or by other
means.
Jordyn Buchanan - It would be good to hear from non-gTLDs.
Dave Crocker - It's an important issue and should be addressed, but it's
notin the critical path of ths group.  EBW - It's been done so this is not
a
Paul Kane - There are rqmts similar to this in some countries.
EL - Straw pole; As is - a few, Changed - none, Deferred - more than as is.
Dan Manly - Does deferring this break any laws in any countries?  Many
Yes's shouted out, no No's.

5.	EPP Status - Scott Hollenbeck

6.	XRP - Eric Brunner-Williams
Slides attached.
Jordyn Buchanan - I prefer distinct documents.  Is it possible to separate
BEEP from Push?  EBW - Yes.
Scott Hollenbeck - I support separate documents.  Push has some problems if
client is off.  Messages need to Que.  I support including it and moving
forward.
Dan Manly - Experience shows that r'ars are having a problem understanding
EPP.  Further extensions would only add to the confusion.
Dave Crocker - I originally thought that polling was the est solution
however the internet comunty has ot had allot of experience with
transaction models the more I learn about it the more I believe that there
are great performance benefits in push.
Jordyn Buchanan - There should be consistency with the event model.
Bruce Tonkin - R'ants should expect different models from different r'ys.
I support push as an option of the core protocol.
Rich Shockey - I support Bruce and disagree with Jordyn.  Let's not
preclude features that support other (non-domain name) r'ys.
Scott Hollenbeck - Push could create push-storms to the r'ars.
Dave Crocker - Queing problems could be solved out of the protocol such and
email.

7.  Notes on GRRP/EPP from an RIR - Cathy Murphy (ARIN)

Presentation Notes:
===========================================================================
ProvReg

Focus: How the drafts might or might not relate to the RIR's (mostly not)

* Current drafts are okay, but definitely domain centric, focus
  on relationships that can be seen with domain registrations

Commonalities:
- do registration of some kind of information at a basic level
- some user scenarios are the same (many ISPs act as re-sellers/brokers)
- similar registration of nameserver information (in-addr.arpa)
- similar registration of contact information (Whois)

Differences/Issues:

*1* fundamental difference: any "rights" of usage of domain name
    ends up with the registrant versus IP control is fundamentally
    hierarchical
    - end-user subject to upstream, whether an ISP, NIR, LIR or RIR
    - IP "transfer" is a top-down, not bottom-up, process
    - IP registration request is not for a specific, identifiable object
      like a domain name; rather, it describes an amount (/18), which they
      might or might not receive.

*2* Most domain registrations (GRRP) tend to be session-oriented, versus
    RIR registration process, which is longer and may extend over several
    days/weeks.
    - EPP 2.0 "All EPP commands are atomic and idempotent."
    - XRP 2.3 "XRP supports four major types of services  ...
      Each of these services is atomic in nature and identifies a logical
      transaction. Each of the requests is idempotent, either succeeding
      completely or failing completely and producing predictable results
      in case of repeated execution."
    - GRRP provides near immediate registration; RIR has a whole analysis
      review period (comparable to if domain registry were required to
      perform research for the other "IP", i.e., intellectual property
      and/or trademark research, and confirm application information)

    * first contact with RIR is more like an application, not registration

*3* RIRs don't have the volume
    - IP and AS Regs: 500 p/wk (max)
    - SWIP's/3000-5000K per day
    - transfers: 2 week minimum to process
    - routing registrations -- "IRR" -- different beast for ARIN; couldn't
      tell you the numbers

*4* Contact info is "technical" versus "social"

SUMMARY:

Suggest that ProvReg change Generic Registry Registrar Protocol (GRRP) to
Generic Domain Registry Registrar Protocol (GDRRP); save GRRP term if and
until there is a core protocol that does speak to registration objects
other than domain names.
===========================================================================
Domains have rights of the name holder.  IP addresses are different.
RIRs don't get requests for specific names.
EPP protocols are connection oriented.  IP addresses are not.  The
processes take longer.
RIRs do not receive the volume of requests DNS R'ys do.  500 in a week
would be allot.
Contact information is technical in nature and not social, there's a rqmt
to disclose it.
EPP needs to go a layer below.
EBW - Are you aware of anyone selling contact databases?  CM - No.
Mark Kosters - There is social data collected by RIRs.  They will need to
be concerned about privacy rights.
EBW - Can GRRP be saved or would you prefer it not be intended for RIRs?
CM - I prefer that it get changed to met RIR needs, but I understand that
there is a time issue here with the gTLD r'ys.
Scott Hollenbeck - Draft and WG goals are specific to domain names.  We
could have a new rqmts for RIRs.
Greg Someone Telnic - Some registries may be required

8.  XRP vs EPP
Poll - WG preference is to hammer the two into one protocol.
Scott Hollenbeck - The XRP extensions can be included as extensions.
Patrick Falstrom - Is it a problem if there were two models?  JB - If we
try it will fail.
Dave Crocker - Worry about long term and high performance.
Scott Hollenbeck - There is interest in writing an SCTP transport.  I don't
want to be forced to implement BEEP right now even though I believe it is a
good thing n the long term.
Mark Nottingham - W3C is also addressing this issue.

--============_-1212417275==_============
Content-Type: multipart/appledouble; boundary="============_-1212417275==_D============"

--============_-1212417275==_D============
Content-Transfer-Encoding: base64
Content-Type: application/applefile; name="%IETF-51_provreg_Data_Collection"
Content-Disposition: attachment; filename="%IETF-51_provreg_Data_Collection"

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAB8AAAAJAAAAXQAAACAA
AAAIAAAAfQAAABBJRVRGLTUxIHByb3ZyZWcgRGF0YSBDb2xsZWN0aW9uU0xEOFBQVDMA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADJilFAyYpRUttDAADKM7F
--============_-1212417275==_D============
Content-Type: application/octet-stream; name="IETF-51_provreg_Data_Collection"
 ; x-mac-type="534C4438"
 ; x-mac-creator="50505433"
Content-Disposition: attachment; filename="IETF-51_provreg_Data_Collection"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAA
AAAAAAAAEAAANgAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
///9////NQAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAAN
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA
GgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA
ACcAAAAoAAAAKQAAACoAAAArAAAALAAAAP7///8uAAAALwAAADAAAAAxAAAAMgAAADMA
AAA0AAAA/v////7////+/////v//////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
bHNlIGlmIChiTmFt
--============_-1212417275==_D============--
--============_-1212417275==_============
Content-Type: multipart/appledouble; boundary="============_-1212417275==_D============"

--============_-1212417275==_D============
Content-Transfer-Encoding: base64
Content-Type: application/applefile; name="%XRP.ppt"
Content-Disposition: attachment; filename="%XRP.ppt"

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAAAcAAAAJAAAARQAAACAA
AAAIAAAAZQAAABBYUlAucHB0U0xEOFBQVDMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD
KMx6AyjMekttDAADKM7F
--============_-1212417275==_D============
Content-Type: application/octet-stream; name="XRP.ppt"
 ; x-mac-type="534C4438"
 ; x-mac-creator="50505433"
Content-Disposition: attachment; filename="XRP.ppt"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAQAA
AAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAB7AAAA////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
--============_-1212417275==_D============--
--============_-1212417275==_============
Content-Type: text/plain; charset="us-ascii"

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

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

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

--============_-1212417275==_============--

Date: Wed, 05 Sep 2001 15:46:58 +0200
From: Klaus Malorny <[email-masked]>
To: Daniel Manley <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, Eric Brunner <[email-masked]>
Subject: Re: Questions about containers
Sender: [email-masked]

Daniel Manley wrote:
> 
> Hi,
> 
> I'm reposting this since I haven't seen a reply yet.  If I missed the
> reply somehow, could someone please send it to me or repost it to the list?
> 
> Many thanks,
> Dan
> 
> Daniel Manley wrote:
> 
> > Eric,
> >

Even for the case that I make myself even more unpopular, I would like to add
two simple questions to the good questions raised by Daniel:

Do the benefits you expect from containers legitimate the enormous amount of
complexity they add to a registry, registrar or reseller system (as they
introduce hierarchical/recursive data structures)? Do you think the normal
end-user is able to understand this concept?

Still, the spec is confusing to me. Some terms are used in a way that is
unfamilar to _me_, the initial ASCII art graphic suggests something different
than what is described in the text. But I will try harder.

As far as I understand the document, the graph should look more like:

      +-------------+
      | Container 1 |--------+   +--------------+
      +-------------+        +-->| Registrant 1 |    "child" objects, 
             |               |   +--------------+    properties????
             |               |
             |               |   +--------------+
             |               +-->|    Host 1    |
             |          ........>+--------------+
      +-------------+   .
      | Container 2 |--------+   +--------------+
      +-------------+   .    +-->|  Contact 1   |
             |          ........>+--------------+
             |          .
             +------------------------------------+
             |          .                         |
             |          |derived           +-------------+
             |          |objects????       | Container 4 |
      +-------------+   .                  +-------------+
      | Container 3 |--------+
      +-------------+   .    |   +--------------+
             |          .    +-->|    Host 2    |
             |          .....|..>+--------------+
             |          .    |
             |          .    |   +--------------+
             |          .    +-->| Registrant 2 |
             |          ........>+--------------+
      +-------------+   .
      |   "linked"  |....
      | Object ???? |--------+
      +-------------+        |   +--------------+
                             +==>| addl. objects|
                                 +--------------+

regards,

Klaus Malorny

___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     [email-masked]             Tel. +49 231 9703 0

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: BEEP Transport 
Date: Wed, 5 Sep 2001 09:01:57 -0400 
Sender: [email-masked]

> -----Original Message-----
> From: Eric Brunner [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2001 4:28 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: BEEP Transport 
> 
> 
> 
> > BEEP does not have an explicit dependency on TCP, though this draft
> > describes TCP connectivity.  Would it be possible to clarify either a
> > specific requirement for TCP transport (expanding on the reference to
> > RFC3081), or note that protocols other than TCP are possible and that
this
> > is just one possible way of moving data around?
> 
> There is a reference to 3080, as well as to 3081. I don't see the problem,
> but do suggest language.

I know this is a very small nit, but I think it important to note that the
requirement for TCP/3081 comes from this document and not from BEEP itself.
A statement to make that clear may answer future questions like "why didn't
they use SCTP?".

I can't provide text to explain why TCP was chosen, though I'll admit that
it's an obvious choice given that it does the job and it's documented,
whereas other transport options are still immature or undefined.  I can
suggest text to let folks know where the requirement is coming from
(reference is paragraph two of section 1, "Introduction").  Please consider
changing this:

"This memo documents how a EPP session is mapped onto a single [BEEP]
session.  [RFC3081] documents how a BEEP session is mapped onto a single TCP
[RFC793] connection."

to this:

"This memo documents how an EPP session is mapped onto a single [BEEP]
session.  [RFC3081] documents how a BEEP session is mapped onto a single TCP
[RFC793] connection.  This profile requires a reliable, connection-oriented
transport that preserves the order of data exchanged between end points.
Though TCP is not specifically required by BEEP, TCP provides the service
attributes required by this profile."

<Scott/> 

Date: Tue, 4 Sep 2001 16:18:32 -0400
From: Michael Mealling <[email-masked]>
To: "Marshall T. Rose" <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], Marshall Rose <[email-masked]>
Subject: Re: BEEP Transport
Reply-To: Michael Mealling <[email-masked]>
Sender: [email-masked]

On Tue, Sep 04, 2001 at 10:25:35AM -0700, Marshall T. Rose wrote:
> > I believe it completely inappropriate for a WG draft to define a profile
> > using vendor-specific URIs.  I'm not aware of any IETF document that
> > describes IETF-standard BEEP profile definition procedures; does such a
> > document exist?  Perhaps one is needed if not, but in the mean time I
> think
> > it would be better to expand on the xml.resource.org precedent used by
> other
> > profiles described in IETF WG documents (such as those defined for TLS and
> > SASL).
> 
> hi. i don't think it will be difficult to set-up a work-in-progress prefix
> for beep profiles that are under development. i'll start moving on that.
> 
> a few working group have been using the xml.resource.org thing as a
> place-holder and no one on the iesg has objected, so i think you're safe in
> provreg to use that until the work-in-progress thing is set-up...

I've have two drafts that are relevent to this:

draft-mealling-iana-urn-01.txt
"An IETF URN Sub-namespace for Registered Protocol Parameters"

and

"The IETF XML Registry"
draft-mealling-iana-xmlns-registry-02.txt

If you want I can add a section that deals with creating temporary URIs
since it will be an issue with the URN namespace anyway...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

Date: Tue, 04 Sep 2001 16:37:33 -0400
From: Daniel Manley <[email-masked]>
To: "[email-masked]'" <[email-masked]>
CC: Eric Brunner <[email-masked]>
Subject: Re: Questions about containers
Sender: [email-masked]

Hi,

I'm reposting this since I haven't seen a reply yet.  If I missed the 
reply somehow, could someone please send it to me or repost it to the list?

Many thanks,
Dan

Daniel Manley wrote:

> Eric,
>
> First, thanks for the drafts.
>
> k, I have some questions and possibly corrections as well:
>
> 1) XRP is mentioned twice without introduction.  Is this leftover from 
> the XRP drafts?
>
> 2) Do containers and their relations to other objects preclude the 
> associations defined in the EPP domain draft?
>
> 3) The registrant -- that is simply a contact right.  I might have 
> missed it but I don't think it explicitly says that.
>
> 4) Can you explain the difference between child objects and linked 
> objects?  That wasn't completely clear to me.
>
> 5) The container delete description specifies that the authInfo must 
> be provided.  This isn't right is it?
>
> 6) In container delete, what is the difference between using the none 
> and the break option?  Taking no action on related objects implicitly 
> breaks their association with the deleted container right?
>
> 7) The following paragraph states that a container should not be 
> deleted if it is associated with other known objects.  Is that really 
> saying that containers can't be delete as long as they have a parent?  
> The way it is worded there, I couldn't help but try to extrapolate a 
> meaning with the previous option element (none, delete, break).  But 
> maybe that's just the way I interpreted it.
>
> 8) How does a registrar know which templates exist in the registry? 
> Will that information be provided out-of-band in contracts or notices 
> from the registry?
>
> 9) Referring to the diagram example in the draft, if a registrar 
> associated a domain to Container 3, would that domain have Host 1 
> (from Container 1) and Host 2 in it's DNS records?
>
> I might forward more questions as I study the document a little more.
>
> Thanks for your help,
> Dan
>
>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: BEEP Transport 
Date: Tue, 04 Sep 2001 16:28:06 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

> BEEP does not have an explicit dependency on TCP, though this draft
> describes TCP connectivity.  Would it be possible to clarify either a
> specific requirement for TCP transport (expanding on the reference to
> RFC3081), or note that protocols other than TCP are possible and that this
> is just one possible way of moving data around?

There is a reference to 3080, as well as to 3081. I don't see the problem,
but do suggest language.

> I believe it completely inappropriate for a WG draft to define a profile
> using vendor-specific URIs.  I'm not aware of any IETF document that

I agree, did I fail to flag any? I use the usual C convention of commented
tripe-X to denote known broken-nes in code, or in this case, XML exchanges.

> describes IETF-standard BEEP profile definition procedures; does such a
> document exist?  Perhaps one is needed if not, but in the mean time I think
> it would be better to expand on the xml.resource.org precedent used by other
> profiles described in IETF WG documents (such as those defined for TLS and
> SASL).

Milage varies. Marshall needs to get some profile namespace, otherwise I
will.

> Rather than using Content-Type: text/xml, the base EPP spec defines an
> application/epp+xml media type.  I'd like to recommend use of this media
> type instead of text/xml.

Thanks.

> The XML Schema references are outdated.  The current references should point
> here:
> 
> http://www.w3.org/TR/xmlschema-1/, and
> http://www.w3.org/TR/xmlschema-2/

Thanks again.

Note to the chairs, I take the transfer from "individual" to "working group"
seriously. If asked I will edit the working group drafts which I was a
co-author. If the chairs and/or the WG designate someone(s) else, I'll give
them the nroff sources.

Eric

From: "Marshall T. Rose" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>
Cc: "Marshall Rose" <[email-masked]>
Subject: Re: BEEP Transport
Date: Tue, 4 Sep 2001 10:25:35 -0700
Sender: [email-masked]

> I believe it completely inappropriate for a WG draft to define a profile
> using vendor-specific URIs.  I'm not aware of any IETF document that
> describes IETF-standard BEEP profile definition procedures; does such a
> document exist?  Perhaps one is needed if not, but in the mean time I
think
> it would be better to expand on the xml.resource.org precedent used by
other
> profiles described in IETF WG documents (such as those defined for TLS and
> SASL).

hi. i don't think it will be difficult to set-up a work-in-progress prefix
for beep profiles that are under development. i'll start moving on that.

a few working group have been using the xml.resource.org thing as a
place-holder and no one on the iesg has objected, so i think you're safe in
provreg to use that until the work-in-progress thing is set-up...

best,

/mtr

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: BEEP Transport
Date: Tue, 4 Sep 2001 15:23:27 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Dave Crocker [mailto:[email-masked]]
>Sent: Tuesday, September 04, 2001 1:50 PM
>To: Hollenbeck, Scott
>Cc: [email-masked]'
>Subject: RE: BEEP Transport
>
>
>At 10:25 AM 9/4/2001, Hollenbeck, Scott wrote:
>>This is the URI used to define the profile in the draft.  Though it is
noted
>>that this is temporary, it is clearly in the namespace of a particular
>>corporate entity.  If we are attempting to define a standard-track
profile,
>>with software implementations that MUST reference a particular URI to
>
>
>ahh.  thanks for the clarification.
>
>I believe that Marshall Rose has initiated a process to fix this.  That is,

>assuming it is the item from him that you just responded to, supporting the

>request for an IETF "temporary" registry.

(For the benefit of those who haven't seen the private correspondence Dave
referred to)

Yes, I believe that's the case, and a temporary registry (with a progression
path to more "permanent" identifiers) would address my comment completely.

<Scott/>

Date: Tue, 04 Sep 2001 10:50:22 -0700
To: "Hollenbeck, Scott" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: BEEP Transport
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 10:25 AM 9/4/2001, Hollenbeck, Scott wrote:
>This is the URI used to define the profile in the draft.  Though it is noted
>that this is temporary, it is clearly in the namespace of a particular
>corporate entity.  If we are attempting to define a standard-track profile,
>with software implementations that MUST reference a particular URI to

ahh.  thanks for the clarification.

I believe that Marshall Rose has initiated a process to fix this.  That is, 
assuming it is the item from him that you just responded to, supporting the 
request for an IETF "temporary" registry.

d/

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: BEEP Transport
Date: Tue, 4 Sep 2001 13:25:07 -0400 
Sender: [email-masked]

>-----Original Message-----
>From: Dave Crocker [mailto:[email-masked]]
>Sent: Tuesday, September 04, 2001 1:12 PM
>To: Hollenbeck, Scott
>Cc: [email-masked]'
>Subject: Re: BEEP Transport
>
>
>Scott,
>
>At 09:37 AM 9/4/2001, Hollenbeck, Scott wrote:
>>BEEP does not have an explicit dependency on TCP, though this draft
>>describes TCP connectivity.
>
>It certainly relies on a reliable, connection-oriented transport that 
>delivers data in the order sent.

Of course -- my only concern is that the current draft refers to 3081
without saying anything to explain the 3081 is one possible transport
mapping of many possibilities.  Someone might well ask "why not SCTP", so I
think it would be a good idea to be just a little more clear when describing
why TCP is required.

>
>>I believe it completely inappropriate for a WG draft to define a profile
>>using vendor-specific URIs.  I'm not aware of any IETF document that
>>describes IETF-standard BEEP profile definition procedures;
>
>What do you mean vendor-specific URI, and how is it relevant to discussion 
>of our use of BEEP?

http://www.neulevel.com/profiles/EPP/1.0

This is the URI used to define the profile in the draft.  Though it is noted
that this is temporary, it is clearly in the namespace of a particular
corporate entity.  If we are attempting to define a standard-track profile,
with software implementations that MUST reference a particular URI to
identify the profile, I think it would be better to use a more neutral
identifier.  Other BEEP profiles defined in IETF documents use identifiers
from the xml.resource.org namespace, for example.

<Scott/>

Date: Tue, 04 Sep 2001 10:11:55 -0700
To: "Hollenbeck, Scott" <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: BEEP Transport
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Scott,

At 09:37 AM 9/4/2001, Hollenbeck, Scott wrote:
>BEEP does not have an explicit dependency on TCP, though this draft
>describes TCP connectivity.

It certainly relies on a reliable, connection-oriented transport that 
delivers data in the order sent.

>I believe it completely inappropriate for a WG draft to define a profile
>using vendor-specific URIs.  I'm not aware of any IETF document that
>describes IETF-standard BEEP profile definition procedures;

What do you mean vendor-specific URI, and how is it relevant to discussion 
of our use of BEEP?

d/

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: BEEP Transport
Date: Tue, 4 Sep 2001 12:37:00 -0400 
Sender: [email-masked]

I've just taken a cursory glance at beep-00, and I have a few
questions/comments:

BEEP does not have an explicit dependency on TCP, though this draft
describes TCP connectivity.  Would it be possible to clarify either a
specific requirement for TCP transport (expanding on the reference to
RFC3081), or note that protocols other than TCP are possible and that this
is just one possible way of moving data around?

I believe it completely inappropriate for a WG draft to define a profile
using vendor-specific URIs.  I'm not aware of any IETF document that
describes IETF-standard BEEP profile definition procedures; does such a
document exist?  Perhaps one is needed if not, but in the mean time I think
it would be better to expand on the xml.resource.org precedent used by other
profiles described in IETF WG documents (such as those defined for TLS and
SASL).

Rather than using Content-Type: text/xml, the base EPP spec defines an
application/epp+xml media type.  I'd like to recommend use of this media
type instead of text/xml.

The XML Schema references are outdated.  The current references should point
here:

http://www.w3.org/TR/xmlschema-1/, and
http://www.w3.org/TR/xmlschema-2/

<Scott/>

Date: Mon, 3 Sep 2001 11:49:19 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: rough cut of minutes
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Sorry about the lateness of this...but it happened.

I have slides from Scott (and my intro material), but no other
presentations (Eric, Cathy-notes, James).

-------------------------------------------------
Provreg Meeting Minutes
8-8-01

1. Agenda bashing - Ed Lewis
Review of milestones
EL - Original milestones were too aggressive.  Second draft was too loose.
New milestones are set to meet the groups needs, so we need to make sure to
keep pressing with the dates in mind.
Review of draft status
EL - Requirements draft is close to RFC, Core EPP draft has some proposed
changes, and other EPP extensions drafts have not yet been reviewed.
Two new non-wg docs; OPP and XRP

2. OPP Presentation - James Sang
Slides <<needed>>.
Mark Nottingham - Did you use existing XML protocol rather than develop a
new DTD?  JS - Other author needs to answer.  MN -I'll bring it to the list
Dave Crocker - What within EPP does not meet the needs of China?  JS - EPP
is a 2 entity protocol, does not support communications btwn other nodes
(r'ant-r'ar, r'ar-r'ar, etc.).  (Ask Dave.)
Eric Brunner-Williams - What kind of graph is OPP?  JS -
Rich Shockey - How will you maintain transactional intergrity btwn the
nodes?  JS - Every request is signed by each node.  RS - Do you prefer any
transport protocol?  JS - No we are transport agnostic.
Dave Crocker - Clarification
Jordyn Buchanan - Can't EPP meet your needs if we added the requirements
for signatures btwn nodes?
W3C Guy - Do you plan on using XML schema rather than new DTD
Dan Manly - How do you make sure proper security is in each node?
Rich Shockey - What application would require coordination btwn four nodes?
Jordyn Buchanan - R'ant need to authenticate with a r'y, discussed on the
list and has been desire of some ccTLDs.  JS - Multiple tiered phone
companies.  Scott Hollenbeck response to JB, current EPP draft doesn't
provide this capability, but there's o reason why it couldn't be updated or
extension added.

EL - Should the WG accept the document?
Dave Crocker - Not good to have two protocol documents but we could try to
address the needs met in the document by integrating it into EPP documents.

EL - It may be best for JS to get the document where he wants it before
accepting it.
George Ballotsky - Process is too rushed to get a good protocol.
EL - We'll take the question to the list.
(Document has since been withdrawn from consideration.)

4.	Data Collection Policy Requirement - Scott Hollenbeck
Slides provided.
Dave Crocker - You can keep the rqmt knowing that it can't be resolved
right now.
Dan Manly - There can be a preference hierarchy.
Eric Brunner-Williams - I've addressed the suggested changes on the list.
R'ys need to distinguish btwn social and technical data.  Policy
announcement by R'ys is the problem that needs to be solved.  P3P is used
as a starting point because it exists, there's no suggestion that Provreg
follow P3P policies or procedures.  SH - What is the information that you
want presented?  EBW - Current policy at the time of the transaction.
Jordyn Buchanan - There are instances where r'ants may want to pick a
policy but r'y contracts dictate what the r'y does.  EBW - R'ars or r'ys
may request data that is above and beyond what is necessary and not
required by the contracts.
Dan Manly - R'ys can provide that information on their websites or by other
means.
Jordyn Buchanan - It would be good to hear from non-gTLDs.
Dave Crocker - It's an important issue and should be addressed, but it's
notin the critical path of ths group.  EBW - It's been done so this is not
a
Paul Kane - There are rqmts similar to this in some countries.
EL - Straw pole; As is - a few, Changed - none, Deferred - more than as is.
Dan Manly - Does deferring this break any laws in any countries?  Many
Yes's shouted out, no No's.

5.	EPP Status - Scott Hollenbeck

6.	XRP - Eric Brunner-Williams
Slides <<needed>>.
Jordyn Buchanan - I prefer distinct documents.  Is it possible to separate
BEEP from Push?  EBW - Yes.
Scott Hollenbeck - I support separate documents.  Push has some problems if
client is off.  Messages need to Que.  I support including it and moving
forward.
Dan Manly - Experience shows that r'ars are having a problem understanding
EPP.  Further extensions would only add to the confusion.
Dave Crocker - I originally thought that polling was the est solution
however the internet comunty has ot had allot of experience with
transaction models the more I learn about it the more I believe that there
are great performance benefits in push.
Jordyn Buchanan - There should be consistency with the event model.
Bruce Tonkin - R'ants should expect different models from different r'ys.
I support push as an option of the core protocol.
Rich Shockey - I support Bruce and disagree with Jordyn.  Let's not
preclude features that support other (non-domain name) r'ys.
Scott Hollenbeck - Push could create push-storms to the r'ars.
Dave Crocker - Queing problems could be solved out of the protocol such and
email.

7.  Notes on GRRP/EPP from an RIR - Cathy Murphy (ARIN)
Domains have rights of the name holder.  IP addresses are different.
RIRs don't get requests for specific names.
EPP protocols are connection oriented.  IP addresses are not.  The
processes take longer.
RIRs do not receive the volume of requests DNS R'ys do.  500 in a week
would be allot.
Contact information is technical in nature and not social, there's a rqmt
to disclose it.
EPP needs to go a layer below.
EBW - Are you aware of anyone selling contact databases?  CM - No.
Mark Kosters - There is social data collected by RIRs.  They will need to
be concerned about privacy rights.
EBW - Can GRRP be saved or would you prefer it not be intended for RIRs?
CM - I prefer that it get changed to met RIR needs, but I understand that
there is a time issue here with the gTLD r'ys.
Scott Hollenbeck - Draft and WG goals are specific to domain names.  We
could have a new rqmts for RIRs.
Greg Someone Telnic - Some registries may be required

8.  XRP vs EPP
Poll - WG preference is to hammer the two into one protocol.
Scott Hollenbeck - The XRP extensions can be included as extensions.
Patrick Falstrom - Is it a problem if there were two models?  JB - If we
try it will fail.
Dave Crocker - Worry about long term and high performance.
Scott Hollenbeck - There is interest in writing an SCTP transport.  I don't
want to be forced to implement BEEP right now even though I believe it is a
good thing n the long term.
Mark Nottingham - W3C is also addressing this issue.

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

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

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

Date: Sat, 01 Sep 2001 12:10:21 -0700
To: Patrick <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Cc: [email-masked]
Sender: [email-masked]

At 10:08 AM 9/1/2001, Patrick wrote:
>Also this should be clearly specified during the greetings (in the
>svcMenu tag), and the client SHOULD be able to refuse that the server
>uses the PUSH (preference it can show during the login command, in
>the options tag).

For the benefit of working group participants who are new to the IETF -- as 
well as to make sure that I and we are all in synch about the effect of 
this SHOULD:

SHOULD means "strongly recommended".  That is, the specification asserts 
that an implementation is allowed to decline to implement the feature, but 
there had better be a very good reason for omitting it.

Also, this use of SHOULD does not mean that the OPERATION of the service 
"should" use it.

Rather, the software is encouraged to support the feature, but the 
specification is not offering advice on its actual use.  That is, the 
software should make the choice available to the operator.

Individual operators decide whether they want to use the feature.  (If the 
software developer chooses to provide the operator with the choice.)

d/

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

To: Patrick <[email-masked]>
cc: [email-masked]
Subject: Re: Message Pushing and TCP Transport 
Date: Sat, 01 Sep 2001 14:51:40 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

> On Sat, Sep 01, 2001 at 12:29:55PM -0400, Eric Brunner took time to write:
> > >> How many messages are waiting?
> > >
> > > The value of the count attribute.
> > > Reading the draft :
> > >   - An OPTIONAL <msgQ> element containing a "count" attribute that
> > >     identifies the number of service messages queued for client
> > >     retrieval.
> > 
> > So no messages are deleted from or added to the queue subsequent to the
> > (atomic) set of events in which a value is written to msgQ->cnt, and the
> > (atomic) set of events when, to use your original, the registrar "gets
> > them[.] (immediately or later at its convenience)"?
> 
> Imagine the client receive the information : 1 message waiting... but
> another one came at the same time (since this is what you imagine, if
> I understood you correctly).
> The client *think* there is only one *new* message.
> So it does a poll to take it.
> With the result it sees that is another one he was not aware of
> previously. Thus he can do the poll again.

Therefore while the inter-arrival time of enqueuement events (latent pushes)
is equal to the interarrival time of dequeuement events (actual polls), and
one additional enqueuement event occurs between enqueue and dequeue service,
the client continues to poll until no enquement event occurs between enqueue
and dequeue events. Off-by one after a fashion.

If the inter-arrival time of enquement events (latent pushes) is less than
the interarrival time of dequeuement events (actual polls), the client
continues to poll, and the queue grows without protocol-constrained bound.
Resource exhaustion, and as Scott suggested, bulk dequeue and external
transport (or bit bucket).

> Where is the big deal ?

OK.

> BTW also if we take a *real* case (not some sort of pure
> conjectures...) like using those messages for transfers notification,
> they do not came 10000/hour or day either...

The enqueuement is taking place on the registry, taking registry resources,
and potentially at rates unconstrained by network bandwidth or rates of
connection.

> > Just to be sure, and I'll make this my last question to you, how many
> > messages are waiting?
> 
> Trying to make me look stupid has no real value I think.

Non-goal.

> I do not think that the provreg protocol want to define precisely how
> to count how many messages are waiting. I think that no real
> implementation will care about that.  What is important is *if*
> messages are waiting or not.
>
> Let me try to again phrase my position (after that I think this
> thread should be closed), because either I am not clear enough, or
> you do not seem (to want) to see my point :

We're probably just chewing the error-recovery bone. We simply differ
over how tasty it is, and if it is something both a registrar and a
registry need to agree upon.

If it (error recovery) isn't specified, and no one wants to spend time on
failure cases, then we were done some days ago. Failure and restart/resync
are registrar- and registry-private matters, specified external to the work
of this WG.

> People are objecting to the poll because it creates overhead (mainly
> because it needs that clients periodically connect to know if
> messages are waiting, they say).

No. If the overhead of deferred message delivery is a burden, the message
may be dequeued without warning, and delivered by other means (I'm fond of
avian carrier). The form of "overhead" is immaterial. One form is servicing
tight-loop polling, another is servicing non-polling.

> I say it is false since there is no need to do specific polls to know
> if messages are waiting, since the draft is good enough to provide
> this information in *normal* results, ie usual business.

Rates of enqueue and dequeue are not necessarily symmetric, nor smooth.

> Using poll, client has nothing to do. It does its usual business.
> Some times he will be warned that they are new messages. After that
> it is up to it to handle this correctly. This *only* was my point.
> About semantics you will need to see with the author of the draft, it
> is not my concern here.
> 
> For the record, I agree to have the PUSH as a MAY, however I totally
> disagree to say that the POLL is bad and should be replaced by the
> PUSH. The POLL should be a MUST and the PUSH a MAY.

OK. There's more important things to do. You've convinced me that there is
no latent design weakness, or at least none significantly greater than any
others potentially present, in epp, that arise in the deaf-registrar model.

Eric

Date: Sat, 01 Sep 2001 10:22:28 -0700
To: Patrick <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Message Pushing and TCP Transport
Cc: [email-masked]
Sender: [email-masked]

At 09:43 AM 9/1/2001, Patrick wrote:
>For the record, I agree to have the PUSH as a MAY, however I totally
>disagree to say that the POLL is bad and should be replaced by the
>PUSH. The POLL should be a MUST and the PUSH a MAY.

One of the nice things about the IETF's style of writing specification 
documents, is that it is acceptable to include some explanatory text and 
pedagogy.

Perhaps it would be helpful to have a brief discussion about polling and 
pushing to explains a bit of the operations (and software) tradeoffs?

That way, "good" vs. "bad" is not the debate, but instead the focus is on 
costs vs. benefits.

d/

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

Date: Sat, 1 Sep 2001 19:08:09 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Message Pushing and TCP Transport
Organization: Gandi
Sender: [email-masked]

On Sat, Sep 01, 2001 at 06:43:07PM +0200, Patrick took time to write:
> For the record, I agree to have the PUSH as a MAY, however I totally
> disagree to say that the POLL is bad and should be replaced by the
> PUSH. The POLL should be a MUST and the PUSH a MAY.

Also this should be clearly specified during the greetings (in the
svcMenu tag), and the client SHOULD be able to refuse that the server
uses the PUSH (preference it can show during the login command, in
the options tag).

Patrick.

Date: Sat, 1 Sep 2001 18:43:07 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Message Pushing and TCP Transport
Organization: Gandi
Sender: [email-masked]

On Sat, Sep 01, 2001 at 12:29:55PM -0400, Eric Brunner took time to write:
> >> How many messages are waiting?
> >
> > The value of the count attribute.
> > Reading the draft :
> >   - An OPTIONAL <msgQ> element containing a "count" attribute that
> >     identifies the number of service messages queued for client
> >     retrieval.
> 
> So no messages are deleted from or added to the queue subsequent to the
> (atomic) set of events in which a value is written to msgQ->cnt, and the
> (atomic) set of events when, to use your original, the registrar "gets
> them[.] (immediately or later at its convenience)"?

Imagine the client receive the information : 1 message waiting... but
another one came at the same time (since this is what you imagine, if
I understood you correctly).
The client *think* there is only one *new* message.
So it does a poll to take it.
With the result it sees that is another one he was not aware of
previously. Thus he can do the poll again.

Even if the second message came later, the client will again later
obtain the information it is waiting.

Where is the big deal ?

BTW also if we take a *real* case (not some sort of pure
conjectures...) like using those messages for transfers notification,
they do not came 10000/hour or day either...

> Just to be sure, and I'll make this my last question to you, how many
> messages are waiting?

Trying to make me look stupid has no real value I think.
I do not think that the provreg protocol want to define precisely how
to count how many messages are waiting. I think that no real
implementation will care about that.  What is important is *if*
messages are waiting or not.

Let me try to again phrase my position (after that I think this
thread should be closed), because either I am not clear enough, or
you do not seem (to want) to see my point :

People are objecting to the poll because it creates overhead (mainly
because it needs that clients periodically connect to know if
messages are waiting, they say).

I say it is false since there is no need to do specific polls to know
if messages are waiting, since the draft is good enough to provide
this information in *normal* results, ie usual business.
Using poll, client has nothing to do. It does its usual business.
Some times he will be warned that they are new messages. After that
it is up to it to handle this correctly. This *only* was my point.
About semantics you will need to see with the author of the draft, it
is not my concern here.

For the record, I agree to have the PUSH as a MAY, however I totally
disagree to say that the POLL is bad and should be replaced by the
PUSH. The POLL should be a MUST and the PUSH a MAY.

Regards,
Patrick.

To: Patrick <[email-masked]>
cc: [email-masked]
Subject: Re: Message Pushing and TCP Transport 
Date: Sat, 01 Sep 2001 12:29:55 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

>> How many messages are waiting?
>
> The value of the count attribute.
> Reading the draft :
>   - An OPTIONAL <msgQ> element containing a "count" attribute that
>     identifies the number of service messages queued for client
>     retrieval.

So no messages are deleted from or added to the queue subsequent to the
(atomic) set of events in which a value is written to msgQ->cnt, and the
(atomic) set of events when, to use your original, the registrar "gets
them[.] (immediately or later at its convenience)"?

As a state machine recovery mechanism such locks are useful when transition
takes place from the normal state management mechanism (push, usually), to
the recovery-and-reset state management mechanism (poll, usually, ignoring
the provreg epp/rrp sense of directionality). Is this what you think we have
in the semantics of msgQ and its two associated types, the unsignedLong and
dateTime?

Just to be sure, and I'll make this my last question to you, how many
messages are waiting?

Eric

Date: Sat, 1 Sep 2001 17:28:21 +0200
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: Message Pushing and TCP Transport
Organization: Gandi
Sender: [email-masked]

On Sat, Sep 01, 2001 at 10:09:18AM -0400, Eric Brunner took time to write:
> ...
> > When the client does it businnes, in any reply he may get a count
> > (but no qDate). If the count exist, it means message are waiting,
> > then it can do a poll to grab them.
> 
> How many messages are waiting?

The value of the count attribute.
Reading the draft :
  - An OPTIONAL <msgQ> element containing a "count" attribute that
    identifies the number of service messages queued for client
    retrieval.

Patrick.

To: Bruce Tonkin <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: Pushing vs. Pulling 
Date: Sat, 01 Sep 2001 10:31:02 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

> I support this middle ground.

Ditto.

Hypothetical complications noted for the deaf-registrar transaction model,
and non-hypothetical requirements noted for the connection==session model,
now lets move on.

I propose that draft-mumble-epp-push-00.txt be adopted as a working group
document, containing:

	a non-argumentative introduction,
	a  specification of a optional (MAY) <push> operation, its operands
	   (objects),
	a formal syntax (got to love that xml), 
	some use case examples (e.g., xfr with <push> ACK only, <push> service
	notices, <push> registry-private policy junk (ENODOLLARS), etc.)
	and the usual considerations (none, none, and none)

Any volunteers itching to write an I-D? It has to push containers, just to
be as general as we've got at present, so epp-4 and -containers are your
starting points, and the peer model in -beep. Possibly also the client/server
model in -tcp, though there appears to be little actual positive interest in
this last variation on the theme.

Eric

To: Patrick <[email-masked]>
cc: [email-masked]
Subject: Re: Message Pushing and TCP Transport 
Date: Sat, 01 Sep 2001 10:09:18 -0400
From: Eric Brunner <[email-masked]>
Sender: [email-masked]

...
> When the client does it businnes, in any reply he may get a count
> (but no qDate). If the count exist, it means message are waiting,
> then it can do a poll to grab them.

How many messages are waiting?