Subject: [apps-discuss] [APPS-REVIEW]apps-team review of , draft-cridland-acap-vendor-registry-01

From: Xiaodong Lee <[email-masked]>
Date: Fri, 15 Oct 2010 16:35:21 +0800

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-cridland-acap-vendor-registry-01

Title: The Internet Assigned Number Authority (IANA) Application 
Configurations Access Protocol (ACAP) Vendor Subtrees Registry

Reviewer: Xiaodong Lee

Review Date: Oct.15 2010

Review Summary: This draft is ready for publication as an Proposed 
Standard and should be revised before publication.

Major Issues:
This document extend the character set from ASCII to UNICODE for 
internationalization, it only defines the valid character scope of 
vendor-name, no string-prep procedures are defined, for example, to deal 
with the full-width and half-width problem, which may cause problems to 
registry.

Minor Issues:
section 3.2  "iana-vendor-tag     = 1*(ALPHA / DIGIT / SP / "-")".
4 types of characters are chosen. Need explanation why these 4 types? 
For example, why not "&" (ampersand)? which is also often appears in 
vendor-name.

Nits:
title: "... Application Configurations ..." should be "Configuration", 
according to RFC2244.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 17 Oct 2010 07:26:42 +0100

Hi Xiaodong,
Thank you for your review.

Xiaodong Lee wrote:

>  I have been selected as the Applications Area Review Team reviewer 
> for this draft (for background on apps-review, please see 
> vendor-name, no string-prep procedures are defined, for example, to 
> deal with the full-width and half-width problem, which may cause 
> problems to registry.

I think you've misunderstood. RFC 2244 allowed for Unicode here already, 
but it never specified any Unicode normalization rules.
This document actually restricts the allowed characters to a subset of 
ASCII, because of existing uses in various IMAP (and Sieve) extensions. 
So no Unicode normalization would be needed.

Having said that, the document might not be very clear on this.

> For example, why not "&" (ampersand)? which is also often appears in 

I will let the author comment on this.

> title: "... Application Configurations ..." should be "Configuration", 

Good catch.