On Mon, Jun 11, 2018, at 15:48, Gould, James wrote:
> JG - Why does the extension data need to reside within the
> <registry:infData> node? EPP already has an extension mechanism that
> can be used, so why not use it in this case?
I have two reasons for this.
The first one being that the XML document in itself can be useful, outside of
the EPP protocol and design over how messages are exchanged.
If all (core + extensions) policies of a given registry are in one and some
document, registrars can use it, for example, to process it and generate some
code based on it. The XML document in this case, that is without any structure
coming from EPP, could evevn be distributed out of band (one may argue that EPP
being a *provisioning* protocol it is not the best to just send information and
while you define the <create> command on this new structure, I doubt many EPP
clients will implement or need to implement it).
The second reason is structure.
You decided to have domain/host/contact as "top" structure, hence mimicking the
3 RFCs about each of them. We can agree on that. But then, RGP and DNSSEC are
their own RFCs and while they are purely related to domain names, it would not
look strange to me that they are top elements themselves, like I wrote each RFC
and/or namespace could be a top element grouping policies related to it.
This would also simplify the whole <registry:services> content.
> JG - Maybe you can provide some sample XML that combines the policy for
> a Registry Zone that supports what is in the Registry Mapping and in the
> Launch Phase Policy Extension to help understand your proposal.
I will try to do that based on other discussions of this draft, to see where
the consensus goes to.
> 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.
>
> JG - The schedule can certainly be enhanced. Can you propose an
> alternative structure to define it?
The current example
<registry:batchJob>
<registry:name>pendingDelete</registry:name>
<registry:description>Pending Delete Batch
</registry:description>
<registry:schedule tz="EST5EDT">0 14 * * *
</registry:schedule>
</registry:batchJob>
could be with ISO8601:
<registry:batchJob>
<registry:name>pendingDelete</registry:name>
<registry:description>Pending Delete Batch</registry:description>
<registry:schedule>R/14:00:00-05:00/P1D</registry:schedule>
</registry:batchJob>
The EDT/EST switch may be a problem and would need two intervals maybe,
each for 6 months during the year (this can be done by start and stop date of
the ISO8601 format)
On a related note, there may be a need here to also encode things such as:
contacts not linked for 30 days are deleted from system
(which means processes that can not be anchored at a specific time)
> 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.
>
> JG - 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.
I still think it is simpler to have UTC everywhere, this also makes registries
fully aware that their operations are indeed international because some of
their registrars may really be from the opposite side of the world.
But at least as long as the timezone is mandatory (and non ambiguous, which
means only offsets from UTC, otherwise things like EST/EDT are ambiguous), is a
step in the good direction.
> I find this unfortunate:
> <registry:name>: The zone name that can be at any level
>
> When you parse it, you read it as "a registry name", but then it is a
> zone.
> So while it could probably not be <zone:name> it should at least be
> <registry:zoneName>.
>
> JG- The label name could be changed, but I believe the most important
> item is the meaning of the element. Since the <registry:name> element
> is a sub-element of the <registry:zone> element, wouldn't it be
> redundant to replicate the zone in the label (<registry:zoneName>) or
> the namespace (<zone:name>)? I don't believe defining a new namespace
> will help here. I believe leaving it as
> <registry:zone><registry:name>EXAMPLE</registry:name>...</registry:zone>
> with a description of the <registry:name> element as meeting the need.
My problem is probably exacerbated by the use of "registry" as namespace alias.
I believe both the name of the extension and hence its XML namespace should be
changed.
> 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.
>
> JG - 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.
I think it would be important to specify the type of the regex that are used.
Unfortunately, like I said, I am not sure all cases should be able to be
expressed, especially with all kinds of regex engine.
Some registries are rules such as: this character can only appear after this
one. While it could be put in a regex, the combinations can explode very fast.
You have the same problem with reservedNames: sometime it is just not a static
list but can have things like "any domain starting with ac- is reserved".
It can also be included by reference and not listed like: list of all cities in
the country.
You may also have separate types of reserved names: some can not be registered
at all, and some can be registered but with additional procedure about
eligibility. This distinction may need to be conveyed.
\w and \d may also be ambiguous as locale dependent (or not, depends on
language and regex flavor I guess), so in case of IDNs that is a problem.
> 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.
>
> JG - 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.
Unfortunately I still think that the whole <registry:idn> part is a rewrite of
what LGRs do, with less features. If they are deemed too complicated this means
either that the features they have are not needed by registries or that we are
trying to implement a subset of them.
In short, I feel uneasy to just forget them and saying we will reimplement part
of them differently.
This would also mean that the same things (IDN handling) can be coded in two
different ways: through your extension and through LGRs.
Questions will arise about this.
> 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)
>
> JG - Is this the case? If so, you are correct that they would need to
> be separated.
Yes, some registries do not allow IPv6 values at all, and some will have
different limits for IPv6 or IPv4.
> For contacts:
> - 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)
>
> JG - 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.
Except if that changed, TRAVEL for example allowed either INT only, or INT+LOC
together, but not LOC alone.
Such kind of things can not be encoded with the above parameters.
> - 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).
>
> JG - That's interesting since in RFC 5733 the contact ID is client-
> specified.
It is *very well* spread in ccTLDs, whatever the RFCs say.
The client can indeed specify whatever it wants (or some registries may impose
a specific value), but the registry will ignore the value and just return the
one allocated in the creData section of the contact:create reply.
This is the case in .FR for example. Or .EU
> 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.
Agreed but with the risk that even less registries will deem it useful to use
your extension if they are not able to encode their current business policies
in it.
> For domain passwords, is <domain:null> allowed?
>
> JG - I know nothing of the use of <domain:null>, so I would be
> interested to further understand it.
RFC 5731 section 3.2.5:
A <domain:null> element can be used within the <domain:authInfo> element to
remove authorization information.
And associated schema:
<!--
Allow the authInfo value to be nullified by including an
empty element within the choice.
-->
<complexType name="authInfoChgType">
<choice>
<element name="pw" type="eppcom:pwAuthInfoType"/>
<element name="ext" type="eppcom:extAuthInfoType"/>
<element name="null"/>
</choice>
</complexType>
>From my notes, and except if it changed recently, .NO uses this feature.
Related to passwords, I think there is nothing about the EPP one (client login).
But you have things like that:
- some registries mandate it to be changed on first login
- some registries mandate it to be changed at least in some frequence (ex: each
183 days).
--
Patrick Mevzek
[email protected]
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
