I'm sorry to not have answered your questions up until now... @Linlin, do you
take into account the remarks of James too?
> On 21 May 2018, at 15:40, Gould, James <jgo...@verisign.com> wrote:
>
> Pieter,
>
> Thanks for doing the detailed review. I’ll let Linlin comment on the
> proposed wording changes. I have feedback on some of the items below:
>
>
> ===
>
> 3.4 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.
> Organization Status Values
>
> I think you forgot to specify that
>
> "linked" status MUST NOT be combined with either "clientLinkProhibited" or
> "serverLinkProhibited" status.
>
> Or is this in case you want to block linking while there are still links? If
> so, it's useful to specify this:
>
> A client or server MAY combine linked with either clientLinkProhibited or
> serverLinkProhibited if new links must be prohibited [...]
>
>
> The purpose of the [client/server]LinkProhibited statuses are to prohibit
> additional links without impacting the existing links, so you second proposal
> would be the most appropriate.
Ok
>
>
> ===
>
> 3.5 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.5>. Role
> Status Values
>
> […]
>
> o ok: This is the normal status value for an role that has no
> pending operations or prohibitions. This value is set and removed
> by the server as other status values are added or removed.
>
> ⇒ There are no pending statuses for role statuses, so remove that part
>
> Also here, I think you forgot to specify that
>
> "linked" status MUST NOT be combined with either "clientLinkProhibited" or
> "serverLinkedProhibited" status.
>
> This is related to the proposal on 3.4 above. There is no need for the
> sentence “"linked" status MUST NOT be combined with either
> "clientLinkProhibited" or "serverLinkedProhibited" status.” since the
> [client/server]LinkProhibited statuses only prohibit future links.
Ok
>
>
> 4.1.2 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-4.1.2>.
> EPP <info> Command
>
> Should we mention what happens in case the querying client is not the
> sponsoring client, or is too much policy?
>
> Yes, I believe that returning the organization object and what organization
> object attributes to return is up to server policy. Maybe it makes sense to
> add a sentence related to it being up to server policy.
That would be great
>
> […]
> When an <info> command has been processed successfully, the EPP
> <resData> element MUST contain a child <org:infData> element that
> identifies the organization namespace. The <org:infData> element
> contains the following child elements:
> […]
> o Zero or more <org:status> elements that contains the operational
> status of the organization, as defined in Section 3.4
> <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.
>
> ⇒ this conflicts with the XML schema and 3.4, which states:
> An organization object MUST always have at least one associated
> status value. The default value is "ok".
>
> I agree that it should it should be “One or more <org:status> elements...” to
> match the XML schema.
Ok
>
> 4.2.5 <https://tools.ietf.org/html/draft-ietf-regext-org-06#section-4.2.5>.
> EPP <update> Command
> [...]
> Zero or more <org:role> elements that contains the role type, role
> statuses and optional role id of the organization
>
> In my opinion the draft is still vague about which role sub-element of role
> is used for matching the role to be removed (I guess it is the role type, as
> it is the only required element). I would mention that:
>
> E.g. in secDNS it is mentioned very explicit;
>
> The <secDNS:keyData> element is part of the Key Data Interface and
> is used to uniquely define the key data to be removed, by using
> all four elements -- <secDNS:flags>, <secDNS:protocol>, <secDNS:
> alg>, and <secDNS:pubKey> -- that are guaranteed to be unique.
> There can be more than one DS record created for each key, so
> removing a key could remove more than one DS record.
>
> The role type is what is unique for the organization’s role. There cannot be
> duplicate role types for an organization. It would be clearer to specify “A
> <org:type> element contains the role type of the organization, as defined in
> Section 3.2. The role type uniquely identifies the role to update.”.
It would have helped me if that would have been included. It'd be nice if this
text is added.
>
> Good instructions for how to remove a contact, I would also add these
> instructies to parentId, voice, fax email and url:
> An empty <org:___> element is supported to allow a type of
> ___ to be removed
>
> ===
>
> Maybe it would be best to adopt the language from IETF-98 “Contact Postal
> Info Elements Discussion”, which included the proposal:
>
> The <contact:chg> sub-elements do have replace semantics
> Existing sub-element data deleted first and then set with updated data.
> <contact:postalInfo> types treated independently
> Exclusion of a <contact:postalInfo> type does not implicitely delete it.
> <contact:postalInfo> type deleted via empty element
> <contact:postalInfo type=”int/> or <contact:postalInfo type=”loc”/>
>
> The elements supported by the <org:add> and <org:rem> are the list elements
> <org:contact>, <org:role>, and <org:status>. The individual attributes
> (postalInfo can be considered two separate attributes “int” and “loc”) are
> updated using the <org:chg>. Maybe the introduction sentence “An OPTIONAL
> <org:chg> element containing the following element, where at least one child
> element MUST be present”, can be revised to clarify how the simple elements
> and complex child elements added, updated, or removed via the <org:chg>
> element. How about something like “An OPTIONAL <org:chg> element used to
> add, update, and delete non-list organization attributes. An empty <org:chg>
> sub-element (<org:parentId>, <org:voice>, <org:fax>, <org:email>, and
> <org:url>, <org:postalInfo> with “type” attribute) is used to remove it and a
> non-empty sub-element is used to replace it. For the <org:postalInfo>
> complex sub-element, the types (“int” and “loc”) are treated independently
> with replace semantics, where the <org:postalInfo> sub-element data is
> deleted first and then set with the update data. The <org:chg> element MUST
> contain one of the following child elements:”.
>
> There is one big item with my proposal in supporting the removal of the
> simple <org:postalInfo> sub-elements using empty elements in that the XSD
> does not support empty elements with the following type definitions:
>
> parentId - eppcom:clIDType
> <simpleType name="clIDType">
> <restriction base="token">
> <minLength value="3"/>
> <maxLength value="16"/>
> </restriction>
> </simpleType>
> voice – org: e164Type
> <complexType name="e164Type">
> <simpleContent>
> <extension base="org:e164StringType">
> <attribute name="x" type="token" />
> </extension>
> </simpleContent>
> </complexType>
> <simpleType name="e164StringType">
> <restriction base="token">
> <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?" />
> <maxLength value="17" />
> </restriction>
> </simpleType>
> fax – org:e164Type
> Same as voice
> email – eppcom:minTokenType
> <simpleType name="minTokenType">
> <restriction base="token">
> <minLength value="1"/>
> </restriction>
> </simpleType>
> url – anyURI
> Does support empty element
>
> The alternative is to make removal explicit with the <org:rem> element by
> supporting a list of empty elements to remove instead of using the <org:chg>
> element with empty elements. For example, the <org:rem> element can support
> removing elements from the list attributes and can be used to remove the
> non-list attributes with empty elements (<org:parentId>, <org:voice>,
> <org:fax>, <org:email>, and <org:url>, <org:postalInfo> with “type”
> attribute). This is different from the semantics for RFC 5733. If this is
> the case, should the <org:add> element only be capable of adding list items
> or should it be used to add non-existing attributes.
>
> Thoughts?
>
To be honest, I think it is OK as it is now. An empty postalInfo to remove it,
otherwise, to update it, provide the complete contents of the postalInfo (if I
understand it well). It's pretty intuitive
>
> ===
>
> Shouldn't we have a section like RFC 5731, 5732, 5733 regarding offline
> review of requested actions?
>
> ===
>
> Yes, that makes sense.
>
> ===
>
> Do we need to remove the Change Log section?
>
> ===
>
> The change log will get removed prior to publication by the RFC Editor.
>
> ===
>
> XSD maxOccurs opinion:
>
> <element name="status"
> type="org:statusType" maxOccurs="9"/>
>
> Why 9? I would set this to unbounded. A client may send an org create with 10
> times clientDeleteProbited. It should just work.
>
> I thought the same thing, but if you do the math, the maximum number of
> unique statuses is 9. The statuses are unique and there should be no
> duplicates. If you look at the RFC 5733, the statuses are defined with a
> maximum, which is being mirrored here based on the unique set of organization
> statuses.
I can live with a 9
>
>
> ===
>
> XSD sequence anti pattern
>
>
> we keep on copying old XML schema's, and hence, for data structures we keep
> on using xsd:sequence (ordered) instead of xsd:choice. If order is not
> important (which is the case in this draft and a lot of other RFCs), don't
> enforce it. It makes implementation and testing often unnecessarily harder.
>
> I don’t view the use of XSD sequence as an anti pattern. I believe the
> sequence makes implementation and testing easier and not harder.
I'm trying to understand how it makes implementation and testing better. When
parsing XML without XML to object binding libraries?
>
>
> ===
>
> Model issue: because org:name is part of org:postalInfo, and org:addr is also
> part of org:postalInfo but required, it is impossible create an organization
> with a name, but without address... I think this must be possible as this was
> one of the first discussions in the mailing list: reseller in a separate
> object vs. or simply add ID and name to a domain.
>
> Proposal: move org:name to a higher level (it's not the name belonging to the
> address of the org, but the name belonging to the org itself)
>
> How about simply making the addr element in the org:postalInfoType optional
> (minOccurs=”0”) and add OPTIONAL to the references to <org:addr> in the text?
This would be a huge improvement. @Linlin, can you change this in both XSD and
text?
Kind regards
Pieter_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
