Thanks Linlin, that helps. If these are following existing patterns, that works for me. On Tue, Oct 30, 2018 at 5:43 PM Linlin Zhou <zhoulin...@cnnic.cn> wrote: > > Dear Martin, > Thank you for your review. Please see my feedbacks inline. > > Regards, > Linlin > ________________________________ > Linlin Zhou > > > From: Martin Thomson > Date: 2018-10-26 05:09 > To: regext > Subject: [regext] draft-ietf-regext-org extensibility comments > Hi, > > I was asked to review draft-ietf-regext-org for the XML namespace and > schema registries. Everything looks fine, except that I think we got > crossed wires somewhere in the back and forth. > > The comment I made was that certain types use xs:enumeration with a > set of values. Here I refer to epp-org:statusType, > epp-org:roleStatusType, and epp-org:contactAttrType. > > The question was whether these types were intended to be extended, or > whether the working group was confident that the list was exhaustive. > Based on the content of the lists, it doesn't appear possible that the > lists could be exhaustive, but maybe there are constraints in this > domain that ensure this is the case. > > The current structure of the schema would prevent these from ever > being extended [1]. The comment was then a question: does the working > group believe that the set of values for these > [Linlin] The above mentioned types have already been existed in other EPP > RFCs except for some unique values specified for EPP organization object. As > far as I know, no registrar or registry has the requirement to extend these > existing type values for the domain business model. Only when proposal for > providing a "grace period" for DNS came out, the Redemption Grace Period > (RGP) status values were extended in RFC3915 which defined a new element in > the EPP extension. Please correct me if I am wrong. > > When I asked, the response was about epp-org:roleType/type. That > confused me. That element is defined as xs:token and has a registry > associated with it, so it's clear that this is extensible. I'm asking > about these enumerated types. > [Linlin] The "registrar", "reseller", "privacyproxy" and "dns-operator" in > this xml-registry are four initial values exsting in the domain > regitrar-registry model. If there are new roles coming out in the future, we > hope they can follow the IANA change control process and be registered in the > existing registry described in section 3 of RFC8126. The new roles should be > known and accepted by most people. > WG discussed about this registry and had some consensus on it. Please refer > to https://mailarchive.ietf.org/arch/msg/regext/RhJGuY2_iswRnMdryDtu2DkFzCs. > > And a bonus question, which I would not have commented on as the > designated expert, but since I'm writing, I'll ask for my own > gratification: Why define yet another addressing format? Just in the > IETF we have a ton of those already. RFC 5139 (of which I'm an > author, for my sins), RFC 6351 (XML vCard), just to start with. > [Linlin] The address format in this document tries to be consistent with EPP > RFCs which is defined in RFC5733. And RFC5733 was updated from RFC3733. I > guess RFC3733 was written in 2004 and there may be no relatively proper > addressing format to reuse then. So the author defined a format for EPP. Of > course this is just my guess:) > > --Martin > > > [1] I guess you could say that the schema isn't normative, and it's > just illustrative. But that is contrary to common practice and would > require a LOT more text for the document to make any sense, because > you would end up relying much more on the text having a normative > description of elements. So I'm assuming here that implementations > will be allowed to reject inputs that fail schema validation. > > _______________________________________________ > 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
