Patrick, Again, thanks for providing the detailed information. I provide my feedback embedded below. — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/17/18, 3:44 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: * 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. JG - I believe the only combination with the single postalInfoTypeSupport element does not cover is "int" being required and "loc" being optional. Of course, the opposite is a possible scenario but highly unlikely. Instead of creating three independent attributes that may not properly cover the exact policy, how about simply adding a fifth enumerated value of "intOptLoc", where the "int" is required and the "loc" is optional? 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? JG - 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. 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? JG - 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. 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. JG - The registry that defines "preferred" would need to better describe it since "preferred" may not come with any additional server behavior that the client needs to account for. * 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 JG - I 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. * 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. JG - 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? * 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. JG - These are elements added by GoDaddy, where support for privacy and proxy contacts are crosscutting policies that I believe do belong. * 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? JG - The reason for Disclosure instead of disclose in <registry:clientDisclosureSupported> is because we're talking about the Disclosure policy of RFC 5733, as in "Disclosure of Data Element and Attribute". Required defines an optional element as required, and supported defines whether an optional element is allowed or accepted. I have the same comment about what the server does with invalid data (e.g., invalid according to the policy), where it is best to define the policy at a higher level with the expectation that the server handles invalid data consistently. * contact:authInfo is not supported by some registries, like contact:id Should that be handled or left to an extension? JG - The contact:authInfo is a required element per RFC 5733, so I believe that defining the lack of support of a required RFC element be left up to a registry-specific policy extension. I assume that you're not proposing removing the definition of the contact:authInfo policy in the Registry Mapping because some registries have decided not to support it. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
