* int/loc
The current 4 values in the draft (loc, int, locOrInt, locAndInt) should be
replaced by 3 independant booleans:
loc = loc only
int = int only
locAndInt = loc+int only
With combinations, that will makes us available to encode all cases I think:
- wide registries accepting every case (so all 3 booleans to yes)
- cases with loc only or int only (very frequent in ccTLDs)
- edge cases like int only or loc+int but not loc only.
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?
Also the 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?
One registry says: "loc preferred if country is local ccTLD one, otherwise int
preferred"
I have no idea what preferred means here and how this could be encoded, if
needed.
* 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
* contact:sp : one registry has this rule "if the contact is in country X - the
registry country - then
the <sp> should be the 2 letters code of the nation provices", that is not free
form.
* privacy/proxy: the extension has:
<registry:privacyContactSupported>: An OPTIONAL boolean value
that indicates whether a privacy contact is supported with a
default value of "true".
<registry:proxyContactSupported>: An OPTIONAL boolean value that
indicates whether a proxy contact is supported with a default
value of "true".
this is however completely germane to RFC5733 so I believe this should not be
there, but in an extension.
* disclose is optional per RFC7333. Many registries ignore it.
Again you have the same problem as above: some registries may just ignore it,
other may reply an error if it
is not allowed but present. The extension should code both cases.
As a generic note I dislike renaming fields for no reason, RFC5733 uses
"disclose" for this, the extension
should use the same name, and not "Disclosure".
Also things are not homogeneous. You have voiceRequired vs
clientDisclosureSupported. I see no reason
for the differences, voice and disclose are at same level in the contact object
and why Required vs Supported?
* contact:authInfo is not supported by some registries, like contact:id
Should that be handled or left to an extension?
--
Patrick Mevzek
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
