Subject: [Gen-art] RE: Gen-ART review of draft-hollenbeck-epp-rfc3733bis-04

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 17 Nov 2006 09:57:07 -0500

Comments below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, October 17, 2006 7:44 AM
> To: [email-masked]; Hollenbeck, Scott; [email-masked]
> Subject: Gen-ART review of draft-hollenbeck-epp-rfc3733bis-04
> 
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-hollenbeck-epp-rfc3733bis-04
> Reviewer: Pasi Eronen
> Review Date: 2006-10-17
> IETF LC Date: 2006-10-12
> IESG Telechat date: (not known yet)
> 
> Summary: This draft is basically ready for publication, but has nits
> that should be fixed before publication.
> 
> Comments:
> 
> This is recycling RFC 3733 to Draft Standard, containing only very
> minor changes. All the comments I have are quite minor and mostly
> editorial in nature:
> 
> 1) The document contains several references to UTF-8 like "names MAY
> be provided in both UTF-8 [RFC3629] and a subset of UTF-8 that can be
> represented in 7-bit ASCII depending on local needs."
> 
> This is not quite correct. UTF-8 is an encoding that converts Unicode
> characters to octets. What the text probably means is that "names MAY
> be provided in both Unicode and a subset of Unicode..."; how Unicode
> is actually encoded depends on the XML declaration, and it's not
> necessarily UTF-8.

The text is accurate as written.  The UTF-8 encoding is what's
acceptable, other possible Unicode encodings are not.  Plus, the XML
declaration is only a hint, not a dependency.

> 2) To me E.164 looks like a normative reference, not merely 
> informative.

It's not used normatively.  The telephone number syntax used in the spec
is derived from E.164, not cited normatively from it.

> 3) Minor editorial nits:
> 
> - References: ISO 3166:1988 is a withdrawn standard; the correct 
>   document is "Codes for the representation of names of countries 
>   and their subdivisions -- Part 1: Country codes", ISO 3166-1:1997.

OK.

> - References: E.164 (1991) is an extremely old version; the latest 
>   approved version is E.164 (02/05).

OK.

> - References: W3C.REC-xml-20040204 is not the latest version of this 
>   spec; is this intentional, or should this be updated to 
>   W3C.REC-xml-20060816?

It's intentional.

> - Appendix A: Section title should be "Changes from RFC 
> 3733", not 3732

Thank you for catching that.

> - Globally: "</epp&gt" -> "</eppgt>" (several instances)
> - Section 5: "<xref target="RFC3339"/>" -> "[RFC3339]"

Will be fixed.

-Scott-

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Mon, 20 Nov 2006 15:05:41 +0200

Scott Hollenbeck wrote:

> > 1) The document contains several references to UTF-8 like "names
> > MAY be provided in both UTF-8 [RFC3629] and a subset of UTF-8 that
> > can be represented in 7-bit ASCII depending on local needs."
> > 
> > This is not quite correct. UTF-8 is an encoding that converts
> > Unicode characters to octets. What the text probably means is that
> > "names MAY be provided in both Unicode and a subset of
> > Unicode..."; how Unicode is actually encoded depends on the XML
> > declaration, and it's not necessarily UTF-8.
> 
> acceptable, other possible Unicode encodings are not.  Plus, the 
> XML declaration is only a hint, not a dependency.

Text later in the document (in Section 5) says that "EPP is
represented in XML", and "conformant XML processors recoginze both
UTF-8 and UTF-16", and "use of UTF-8 is RECOMMENDED in in environments
where parser encoding support incompatibility exists".  3730bis also
explicitly mentions using other encodings than UTF-8 (although it also
recommends UTF-8).

So it seems that other Unicode encodings _are_ acceptable in this
context...?

Best regards,
Pasi