draft-gould-carney-regext-registry-02 supports 4 possible values for the Postal Info Type Support (registry:postalInfoTypeSupport element): "loc", "int", "locOrInt", and "locAndInt".

Patrick Mevzek posting the comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/YS_l_U8x7gIflI8xX9iq_n6vNxE):

• I think the design around int/loc policy does not capture all cases.
  Some registries allow int only; some loc; some int only or int+loc, some loc only or int+loc, some int only or loc only or int+loc, etc.
  (I am not saying all combinations exist, but there are at least more than one of them so we need to be able to handle that)

Jim Gould replied to the comment with:

I'm looking for the other registries to identify whether their policy can be reflected with the "loc", "int", "locOrInt", or "locAndInt" <registry:postalInfoTuypeSupport values. If not, I would like to know why and how it can be changed to support their policy.

There are many uses of regular expression, where the naming of the regular expression elements and the cardinality (one or many) is not consistent. For example for the domain label syntax, there are many registry:regex elements, for the host label syntax, there are many registry:nameRegex elements, and for the contact id syntax, there is a single registry:contactIdRegex element. The first is to use consistent naming, for example the domain label regular expression should be registry:nameRegex instead of simply registry:regex, and second it needs to be decided whether regular expressions should be a many or single cardinality.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/1dmEN0Tg5xcSKOef1UFWtA1RFXA):

I have hinted in the past that I believe another structure for the XML piece of data about zone policies could provide more benefits, such as:

• by not having parts of the information inside an EPP extension under , but everything in the same document it means the document can be published as is; I think this can help resolve the bootstrap problem discussed during the meeting as the XML document, both its "core" part defined by this draft and all extensions inside of it defined by other drafts, could be published as is under whatever channel the registry decides, for example HTTPS, on a public or authenticated website depending on its own wishes.

• by doing so you reduce the risk of having multiple registries implement the same extension to encore the same policy (ex: what are the extra attributes for a contact, if they are the same between the 2 registries) in different documents with different namespaces

• you simplify the writing of extensions, there is much less boilerplate coming from just the fact that you need to reuse EPP extension framework.

So here is my proposal, first the current (simplified) structure to have a base to compare to, and then my suggestion which can be refined in many ways, and specifically the naming of attributes.

I believe that in such way the core document is not held up by any future extensions, as it just define how to add extensions, with an unlimited number of unorderer slots, one per policy group (each group tied to a specific XML namespace, hence a specific document)

CURRENT DOCUMENT

registry:zone
registry:name...
registry:group...
registry:services...
registry:svcExtension...
...
registry:domain
... all policies related to domains, including RGP and DNSSEC
</registry:domain>
registry:host
... all policies related to hosts
</registry:host>
registry:contact
... all policies related to contacts
</registry:contact>
</registry:zone>

ALTERNATIVE PROPOSAL

registry:zone
registry:name...
registry:group...
...

<registry:policies for="urn:ietf:params:xml:ns:epp-1.0">
... all policies regarding session commands, login, poll, etc.
previous registry:services and registries:svcExtension would be there
</registry:policies>

<registry:policies for="urn:ietf:params:xml:ns:domain-1.0">
... all policies regarding domains
</registry:policies>

<registry:policies for="urn:ietf:params:xml:ns:host-1.0">
... all policies regarding hosts, absent if hosts are attributes
</registry:policies>

<registry:policies for="urn:ietf:params:xml:ns:contact-1.0">
... all policies regarding contacts
</registry:policies>

<registry:policies for="RFC5734">
... everything related to the transport, if needed
(not sure about that, or if this can be in the first registry:policies block
with RFC5730 data; I am not fond of the namming either in this case)
</registry:policies>

<registry:policies for="urn:ietf:params:xml:ns:secDNS-1.1">
... all policies regarding DNSSEC, if supported by registry
</registry:policies>

<registry:policies for="urn:ietf:params:xml:ns:rgp-1.0">
... all policies regarding RGP, if supported by registry
</registry:policies>

<registry:policies for="urn:ietf:params:xml:ns:launch-1.0">
... all policies regarding launchphase,
instead of a separate launch-policy extension document
</registry:policies>

<registry:policies for="http://someregistry.example/epp/localExtension">
... all policies regarding this registry specific EPP extension
</registry:policies>

</registry:zone>

Jim Gould's reply to comment on the REGEXT mailing list:

Thank you for providing your approach proposal. I restructured the Registry Mapping and Launch Phase Policy Extension schemas and samples to see how it would work. I found your proposal to be elegant, but in the end I don't believe that it's the path that we should go. After trying out both approaches, I believe that defining a single Registry Mapping EPP object extension along with an extensible set of command / response extensions, per the extensibility built into EPP, as being the best path forward based on the following reasons:

1. No additional extension mechanism is needed
   * Clients and servers would be required to support a Registry Mapping specific extension mechanism to support a pluggable set of Registry Mapping Policy Definitions.
2. EPP clients and servers are capable of negotiating the supported XML namespaces
   * There is no support in the EPP greeting or login command to define the supported Registry Mapping Policy Definition XML namespaces, since the object and extension services identify true EPP extensions.
3. A single Registry Mapping XML namespace is simpler
   * Splitting the single Registry Mapping XML Namespace into a Registry Mapping Namespace with 5 policy XML Namespaces is more complex.
4. EPP is an XML document
   * EPP does not represent a bootstrapping issue.

Overall, I don’t see a compelling argument for restructuring the Registry Mapping.

A "patrick-proposal" directory was added to the GitHub project that includes a candidate set of XML schemas that resembles Patrick's proposal and a set the Registry Mapping and Launch Phase Policy Extension samples restructured based on Patrick's proposal.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/l1x3ods6hGkdA9fi2yOqqI9WdCc):

• contact:sp : one registry has this rule "if the contact is in country X - the registry country - then
  the should be the 2 letters code of the nation provinces", that is not free form.

Jim Gould's reply to comment on the REGEXT mailing list:

That would be really difficult to communicate declaratively if the rule is derived from the value of a different element (e.g,. contact:cc). So, this policy only applies if the contact:cc matches the country code of the registry?

I believe this is best handled via a server-specific policy extension, since it is unique and will lead to undue complexity in defining a generic solution.

Mario Laffredo's feedback on the REGEXT Mailing List (https://mailarchive.ietf.org/arch/msg/regext/lwRzkRaERh1sKANcvk9veHOj7ZU):

The description of expiryPolicy contains the following sentence:

"autoRenew": The domain object will auto-renew at expiry.
                           The client can receive a credit for the 
auto-renew if the
                          domain object is deleted within the auto-renew 
grace period."

Does it make sense to replace "if the domain object is deleted" with "if 
the domain object is deleted or transferred" ?

It was agreed to revise the "autoRenew" description to be:

The domain object will auto-renew at expiry. The client can receive a credit for the auto-renew if the domain object is deleted or transferred within the auto-renew grace period.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/T33Zp_4pmwd94K_QuEDA6cPHK7Y):

• about periods
  how is the new expiration date computed after a transfer: for some registries it is like a start of a new contract, hence the expiration is the date of transfer + 1 year In the same way, sometimes a registrant change (often through a separate command) is deemed to be a new contract
  starting at the command time, hence it changes the expiration.

Jim Gould replied to the comment on the REGEXT mailing list:

You mean the transfer is not treated as a renewal and sets a new expiration date independent of the expiration date prior to the transfer? How many registries do this (many, some, few, or just one)?

Having the transfer command not function as a renewal command or an update command (registrant change) impacting the expiration date is not inline with RFC 5731. We need to know how common these are, where if they are uncommon is best suited for definition in a server-specific policy extension.

Comment by Mario Loffredo on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/lwRzkRaERh1sKANcvk9veHOj7ZU):

Considering that RFC 5730 defines a response code returned when a server receives an unimplemented command (i.e. 2101) , maybe it's worth to add information about unimplemented operations.

Jim Gould's reply to the REGEXT mailing list:

Good point, we can put some thought into how to define this.

This includes both cases of an unimplemented command and an issue of client authorization to execute the command. In the introduction the sentence "It is up to server policy to define what clients are authorized to execute which commands on which registry zones." could be updated to "It is up to server policy what commands are supported and to define the clients that are authorized to execute the commands for the registry zones. The server MUST return a 2101 error response for an unimplemented command and MUST return a 2201 error response for an unauthorized command."

draft-gould-carney-regext-registry-04 defines the "dayOfWeek" attribute as being between 0 (Sunday) to 6 (Saturday). This needs to be updated to follow the ISO-8601 standard to be between 1 (Monday) to 7 (Sunday).

Patrick Mevzek posted comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/YS_l_U8x7gIflI8xX9iq_n6vNxE):

You are speaking about "regex" in various places without referencing how is this formatted. There are multiple de facto regex "standards" so care must be taken there to reference precisely what kind of regex are manipulated.

Also, for example for passwords, some registries policies are not possible to express (only) in regex I think, so there might be a blind spot here.

Jim Gould's reply on the REGEXT mailing list:

Do you have a proposal of how to precisely define the regex? I'm looking for the other registries to review the draft and weigh in on how they can effectively communicate their policies.

Patrick Mevzek posted comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/YS_l_U8x7gIflI8xX9iq_n6vNxE):

alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported and maybe others (all the IDNs ones) should be removed and instead LGRs (RFC7940) should be used/referenced: far more complicated but at least you cater for all cases.

Jim Gould's reply on the REGEXT mailing list:

I agree that this would get much too complex for what we're attempting to solve here. The alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported elements are booleans that clearly define registry policy on what can be supplied. I would like to know about the registry policies that go beyond these booleans and the regex element.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/l1x3ods6hGkdA9fi2yOqqI9WdCc):

RFC5733 says "If a localized form (type="loc") is provided, element content MAY be represented in unrestricted UTF-8."
some registries do restrict the set of characters allowed, so should that be encoded there?

Jim Gould reply to comment on the REGEXT mailing list:

That is a good question. How are the characters being restricted and how would those restrictions be represented? This would come down the regular expression topic that we're having with other attributes.

Patrick Mevzek posting on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/YS_l_U8x7gIflI8xX9iq_n6vNxE):

For IP addresses (min/max) you may need to separate between IPv4 and IPv6 as some registries may impose different constraints to each (including: IPv4 allowed but not IPv6)

Jim Gould's reply on the REGEXT mailing list:

Is this the case? If so, you are correct that they would need to be separated.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/T33Zp_4pmwd94K_QuEDA6cPHK7Y):

• about periods

• something around maximum expiration date, like the ICANN rule on 10 years max and what happens for commands that would go beyond that (ex: create for 9 years and immediate renewal for 5)

Jim Gould reply to comment on the REGEXT mailing list:

What are the possible set of policies out in the wild? We clip the fractional period past the maximum year (10.5 years would become 10 years and attempting to go 11 or more years would fail).

We need additional information related to the possible set of policies from the registries. Right now the only policy discussed on the list is clipping fractional days beyond the maximum expiration date, but exceeded the maximum expiration by a full unit (year or month) will result in an error.

Patrick Mevzek posting the comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/YS_l_U8x7gIflI8xX9iq_n6vNxE):

For domain passwords, is domain:null allowed?
(an arcane part of the standard that I know one registry does)

This is a feature included in RFC 5731 if removal of the authorization information is supported. To address this policy, under the registry:domain element the boolean registry:nullAuthInfoSupported element can be added with a default value of "false". The element could be defined as:

registry:nullAuthInfoSupported: An OPTIONAL flag indicating whether the domain:null element is supported to remove the authorization information with a default value of "false".

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/l1x3ods6hGkdA9fi2yOqqI9WdCc):

• contact:id format, the extension has:

registry:contactIdRegEx: The OPTIONAL regular expression used
to validate the contact:id element defined in [RFC5733].

I do not think this covers all cases. For example some registry gives each registrar a prefix and all contact IDs of this registrar must start with the given prefix. But it is different per registrar. How to encode that policy? Or cases like: "at least one upper case character". This can very fast provoke explosion of combinations if only written by a regex

Jim Gould's reply to comment on the REGEXT mailing list:

I am really not sure what value a registry has in requiring a unique prefix per registrar for the contact:id element, but if this needed to be included then I would propose adding an optional registry:contactIdPrefix element. The registry:contactIdPrefix could include the value "clientPrefix" with a description that states that the contact ID must be prefixed with a client specific prefix defined by the server. The registry:contactIdRegEx could define the format independent of the prefix.

Comment by Mario Loffredo on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/lwRzkRaERh1sKANcvk9veHOj7ZU):

In my opinion, the schedule format has some limits. Java EE Timer expressions (https://docs.oracle.com/javaee/7/tutorial/ejb-basicexamples004.htm) seem to be more flexible especially regarding dayOfMonth values:

1 to 31. For example: dayOfMonth="15".

–7 to –1 (a negative number means the nth day or days before the end of the month). For example: dayOfMonth="–3".

Last. For example: dayOfMonth="Last".

[1st, 2nd, 3rd, 4th, 5th, Last] [Sun, Mon, Tue, Wed, Thu, Fri, Sat]. For example: dayOfMonth="2nd Fri".

Jim Gould's reply on the REGEXT mailing list:

The schedule format was our first attempt, so we can consider your proposal as well.

The registry:schedule element is defined to use the crontab format in draft-gould-carney-regext-registry-02.

Comment by Patrick Mevzek on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/YS_l_U8x7gIflI8xX9iq_n6vNxE):

More specifically now, about "2.3. Schedule" I am strongly against using the format proposed for at least 2 reasons:

• crontab format is not a standard, and is ambiguous for various points
• it encodes a format as a string which is itself in a formatted structure since it is XML. "Hijacking" some free form space when you are in formatted structure seems wrong to me and shows that the structure is not correctly formatted because if it were you would not have to inject a new format in a free text.

Why not use ISO8601 Repeated Time Interval format? We are then still gulty of the previous point but at least it is a standard.
Otherwise please amend the XML structure to break the content currently in the crontab format.

Jim Gould's reply on the REGEXT mailing list:

The schedule can certainly be enhanced. Can you propose an alternative structure to define it?

Comment by Patrick Mevzek on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/YS_l_U8x7gIflI8xX9iq_n6vNxE):

As for timezones, all EPP standards always used UTC for all timestamps (and even if some registries on the field do not respect that), and I think it would be best to stick to that, so that removes the "tz" attribute.

Jim Gould's reply on the REGEXT mailing list:

Yes, that is the case for communicating dates (create date, expiration date), but not the case when it comes to defining a schedule for a batch component that runs based on a local time zone.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/mbSFC2lF-T5JINSslWbnU7MR7go):

• some registries do not allow all possible values for IP addresses. For example one is saying that it will refuse any IP provided if it is in RFC 1918 or 3330 or 3927 or 4193 or 3879. Of course other registries may have the same exclusion list or another. So that should be expressed.

Jim Gould reply to the comment on the REGEXT mailing list:

Good point, there are invalid IP ranges. I don't believe we want to embed the list of invalid IP ranges within the Registry Mapping, but it may make sense to enable referencing an external resource (e.g., URL) that does define it.

We could add a list of registry:invalidIP elements under the registry:host element with the description:

registry:invalidIP: Zero or more registry:invalidIP elements that define the URI of an externally defined list of invalid IP addresses. The IP addresses referenced by the list of registry:invalidIP elements should be combined and normalized by the client to define the complete set of invalid IP addresses.

Patrick Mevzek posted the comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/YS_l_U8x7gIflI8xX9iq_n6vNxE):

For the contact ID some registries let the registrars choose it (per the RFC5733 spirit) but some do not and just choose instead of them; it should be possible to encode this in the policy; there may also be the need to encode that in some cases the prefix of contact ids is not free, but fixed per registrar; maybe a need too to define what happens when 2 registrars try to create the same contact ID, depending on if they are global to the system or local to each registrar (the ROID would be different of course).

Jim Gould replied to comment on the REGEXT mailing list:

That's interesting since in RFC 5733 the contact ID is client-specified. I'm sure this is not the first case where registry policy is not following the RFC, so we need to be careful in trying to support one-off policies that are not in line with the RFCs. With that in mind, if this is a general case, draft-gould-carney-regext-registry can certainly be updated to define the various general policies. We just need to be careful.

According to Mario Loffredo on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/lwRzkRaERh1sKANcvk9veHOj7ZU):

According to section 1.1 of RFC 5731, a server cannot support the host object. So, even if the server implements a policy about IP addresses included in domain:hostAddr elements, it doesn't implement check (or any other) operation on hosts
Therefore, a minOccurs="0" attribute should be added to the element maxCheckHost of hostType.

We need to take a closer look at how hostAddr can be supported in draft-gould-carney-regext-registry including the XML schema definition of maxCheckHost.

Comment by Mario Loffredo on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/lwRzkRaERh1sKANcvk9veHOj7ZU):

Why should supportedStatus only contain standard status ? The 
supportedStatusType definition is less strict than the description and 
this seems good to me because supportedStatusType can match custom 
status too.

Jim Gould reply to REGEXT mailing list message:

It would be good to understand how custom statuses are supported to effectively define the policy for custom statuses. Can you provide a description of how custom statuses are supported? You are correct that the supportedStatusType is not an enumerated type, so therefore any status can be included.

Since the XML schema supportedStatusType is not an enumerated list, then one potential solution is to revise the language of the draft to read:

"The OPTIONAL set of supported domain statuses that SHOULD match the statuses defined in [RFC5731]."
"The OPTIONAL set of supported host statuses that SHOULD match the statuses defined in [RFC5732]."
"The OPTIONAL set of supported contact statuses that SHOULD match the statuses defined in [RFC5733]."

By adding the normative SHOULD, custom statuses can be supported but the standard statuses should be used.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/l1x3ods6hGkdA9fi2yOqqI9WdCc):

What happens when registrar sends here an information the registry does not want (like sending loc+int
where the registry wants only loc)? I see two cases: the registry generates an error or the registry
drops (ignores) the part it does not need. Should that be encoded in the extension?

Jim Gould's reply to comment on the REGEXT mailing list:

I believe that if something doesn't follow the defined policy, it should result in a failure. If a server ignores data instead of failing a command due to not following the defined policy, then that would need to be defined a higher level; although I don't believe ignoring data passed by the client is appropriate server behavior. Maybe we can define a higher level zone-level element that defines how the server handles data that doesn't follow the policy (e.g., registry:invalidData with a value of "fail" or "ignore"). The registry should at a minimum be consistent in how invalid data.

The server should handle extra data (e.g, elements not supported or no-applicable EPP extensions), in a consistent manner, where extra data should result in a failure but may be ignored by the server. To define the policy, the optional registry:invalidData element can be added under the registry:zone element that is defined as:

registry:invalidData: The OPTIONAL policy associated with receipt of extra data sent by the client to the server. The extra data may be an unsupported element or extension. The possible values for the registry:invalidData element include:
"fail": The server will fail a command that includes extra unsupported data.
"ignore" The server will ignore a command that includes extra unsupported data.

Need to fix the misspelling in the sentence '..."accessible" to indicate the zones that are assessible to the client...' to '..."accessible" to indicate the zones that are accessible to the client...'.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/T33Zp_4pmwd94K_QuEDA6cPHK7Y):

• contacts, the extension has:
  registry:contact: Zero or more registry:contact elements
  that defines the minimum and maximum number of contacts by
  contact type.

This will not cover all cases, like those:

• admin contact is optional and falls back to registrant
• since you allow for custom type (and I disagree with that here), some registries have other contact types,
  let us say "other" and have rules like: at least one contact of type technical or other.

Jim Gould reply to comment on the REGEXT mailing list:

Can you provide a proposal of how to define this? The use of "custom" is a pattern that has been followed elsewhere to enable an extensible set of values. If a registry does have "other" or "custom" contact types, they can fully define the min and max policies for their custom contact type.

The Registry Mapping does support domain contact min and max policies with support for custom types via the "custom" enumerated value and the "name" attribute defining the custom contact type. This will handle the basic min and max policy for all of the server contact types. What is not supported is the relationship across contact types (e.g., must have one "technical" or "other" contact type defined). These cross-contact type rules could get very complex, where the draft would morph for being declarative to requiring some form of domain specific language (DSL). I prefer to keep the draft declarative and to offload more complex policies to a server-specific policy extension if required.

Patrick Mevzek comment on the REGEXT mailing list (https://mailarchive.ietf.org/arch/msg/regext/T33Zp_4pmwd94K_QuEDA6cPHK7Y):

• about secDNS, one registry has this:
  keyData only, flags muts be 257, protocol 3 and any algorithm.
  While indeed protocol 3 is the only value possible, the secDNS extension
  could allow other value for flags even if 257 is the only one making sense, and the only one used in examples. Should we care to codify these limits?
  Things may be different with CDS/CDSNKEY, I am not sure.

draft-gould-carney-regext-registry-02 supports the min / max DS or keys supported along with the supported set of algorithms and digests. What is not defined are the supported protocols and flags, where protocol 3 and flags 257 are the values that make sense today. To address this, a list of supported flags and protocols can be added for the registry:keyDataInterface. For example:

registry:flags: Zero or more registry:flags elements that define the supported flags field values as described in RFC 4034.
registry:protocol: Zero or more registry:protocol elements that define the supported protocols as described in RFC 4034.