Re: [regext] WGLC: https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll

["Hollenbeck, Scott" <[e-mail]>]

Thanks, I think that would help.

Scott

> -----Original Message-----
> From: Gould, James
> Sent: Friday, January 19, 2018 12:48 PM
> To: Hollenbeck, Scott <[e-mail]>; '[e-mail]'
> <[e-mail]>; '[e-mail]' <[e-mail]>
> Subject: Re: [EXTERNAL] Re: [regext] WGLC:
> https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll
>
> Scott,
>
> I can add text describing the "name" and "op" attributes in draft-ietf-
> regext-change-poll as being ASCII identifiers to clarify this.
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 1/19/18, 12:24 PM, "Hollenbeck, Scott" <[e-mail]>
> wrote:
>
>     > -----Original Message-----
>     > From: Gould, James
>     > Sent: Friday, January 19, 2018 12:02 PM
>     > To: Hollenbeck, Scott <[e-mail]>;
> '[e-mail]'
>     > <[e-mail]>; '[e-mail]' <[e-mail]>
>     > Subject: Re: [EXTERNAL] Re: [regext] WGLC:
>     > https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll
>     >
>     > Scott,
>     >
>     > Thank you for your review and feedback.  I provide my answers to the
>     > feedback below.
>     >
>     > —
>     >
>     > JG
>     >
>     >
>     >
>     > James Gould
>     > Distinguished Engineer
>     > [e-mail]
>     >
>     > 703-948-3271
>     > 12061 Bluemont Way
>     > Reston, VA 20190
>     >
>     > Verisign.com <http://verisigninc.com/>
>     >
>     > On 1/18/18, 12:16 PM, "regext on behalf of Hollenbeck, Scott"
> <regext-
>     > [e-mail] on behalf of [e-mail]> wrote:
>     >
>     >     > -----Original Message-----
>     >     > From: regext [mailto:[e-mail]] On Behalf Of
> James
>     > Galvin
>     >     > Sent: Friday, January 12, 2018 8:29 AM
>     >     > To: Registration Protocols Extensions <[e-mail]>
>     >     > Subject: [EXTERNAL] [regext] WGLC:
>     > https://datatracker.ietf.org/doc/draft-
>     >     > ietf-regext-change-poll
>     >     >
>     >     > The document editors have indicated that the following
> document is
>     > ready
>     >     > for submission to the IESG to be considered for publication as
> a
>     > Proposed
>     >     > Standard:
>     >     >
>     >     > Change Poll Extension for the Extensible Provisioning Protocol
> (EPP)
>     >     > https://datatracker.ietf.org/doc/draft-ietf-regext-change-
> poll-06
>     >
>     >     Comments:
>     >
>     >     There probably shouldn't be any normative language in the
> abstract.
>     > Please change "MAY" to "may".
>     >
>     > Done
>     >
>     >     Section 3.1.2: does the name attribute for the "custom" case
>     > identifier have an i18n considerations?
>     >
>     > No, this matches the use of the “name” attribute of the “custom”
> phase in
>     > draft-ietf-regext-launchphase and the use of the “op” attribute of
> the
>     > “custom” operation in draft-ietf-regext-change-poll.  In this case
> as with
>     > the other cases, these are custom identifiers that don’t have i18n
>     > considerations.
>
>     I'm not sure I agree with that. This is what I see in the Schema from
>     draft-ietf-regext-launchphase:
>
>          <complexType name="phaseType">
>            <simpleContent>
>              <extension base="launch:phaseTypeValue">
>                <attribute
>                  name="name"
>                  type="token"/>
>              </extension>
>            </simpleContent>
>          </complexType>
>
>     The value associated with a "name" attribute is an XML Schema token
> data type.
>     These are strings. If an attribute value like
> "mañana"(<changePoll:caseId
>     name="mañana">custom</changePoll:caseId>) is legit, isn't there a need
> for a
>     language tag? If not, maybe some more text is needed (in multiple
> documents,
>     perhaps) to explain that these identifiers are not intended to be
>     human-readable character strings and only ASCII characters should be
> used. If
>     character limitations are needed it would be worth exploring how to
> enforce
>     that restriction in the schema.
>
>
>     >     Section 5.1: The title of this section is "XML Namespace", but
> it
>     > seems to be conflating a registration request for an XML namespace
> and the
>     > XML Schema described in Section 4. I'm going to recommend
> registering both
>     > the namespace and the schema in the same way it's done in, for
> example,
>     > RFC 5731.
>     >
>     > I went ahead and revised the IANA Considerations section to match
> RFC 5731
>     > and draft-ietf-regext-launchphase.
>
>     Thanks. All good!
>
>     Scott
>