From stpeter@stpeter.im Thu Jan 10 10:16:01 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29721F8A11 for ; Thu, 10 Jan 2013 10:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4-7Om+C75vJ for ; Thu, 10 Jan 2013 10:16:00 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3443021F8A0D for ; Thu, 10 Jan 2013 10:16:00 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AF70C40458; Thu, 10 Jan 2013 11:21:13 -0700 (MST) Message-ID: <50EF055E.9040605@stpeter.im> Date: Thu, 10 Jan 2013 11:15:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alexey Melnikov References: <20121205144844.60e29b80cd96e2f9acfe1af5@jprs.co.jp> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "precis@ietf.org" Subject: Re: [precis] WGLC: draft-ietf-precis-nickname-05.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:16:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Sorry about the delayed reply.) On 12/9/12 6:38 AM, Alexey Melnikov wrote: > Hi, > > On 5 Dec 2012, at 05:48, Yoshiro YONEYA > wrote: > >> Dear all, >> >> This message starts two weeks Working Group Last Call (WGLC) on >> draft-ietf-precis-nickname-05.txt (Preparation and Comparison of >> Nicknames). >> >> Please review the document and send comments to the list, the >> co-chairs, or the authors >> (draft-ietf-precis-nickname.all@tools.ietf.org) by the end of >> WGLC. >> >> The WGLC will end on Wednesday, Dec 19th. > > I read the document and support its publication. Only a small issue > from me: > > 6.2. Informative References > > [I-D.yoneya-precis-mappings] YONEYA, Y. and T. NEMOTO, "Mapping > characters for PRECIS classes", draft-yoneya-precis-mappings-03 > (work in progress), October 2012. > > I think this reference is Normative, as it is used with a MAY > requirement. (I think keeping the MAY is fine. We need to progress > draft-yoneya-precis-mappings) We need to progress it all. :) To me, saying "other mappings MAY be applied, *such as* X" doesn't mean that X is normative in the sense of the IESG statement: Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work. But, as I say, we need to progress it all, so let's get these documents finished... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDvBV4ACgkQNL8k5A2w/vyegACfQs3UnV9RZIw7xE4qVGgF7BcU XDoAmgJNFzv5PpGAylYAFuLQuKVwXoGo =J7rW -----END PGP SIGNATURE----- From internet-drafts@ietf.org Tue Jan 22 08:29:15 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1D821F8A89; Tue, 22 Jan 2013 08:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBDFIh-AaM+l; Tue, 22 Jan 2013 08:29:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A89E21F8A8F; Tue, 22 Jan 2013 08:29:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122162914.14484.76714.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 08:29:14 -0800 Cc: precis@ietf.org Subject: [precis] I-D Action: draft-ietf-precis-problem-statement-09.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:29:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Preparation and Comparison of Internation= alized Strings Working Group of the IETF. Title : Stringprep Revision and PRECIS Problem Statement Author(s) : Marc Blanchet Andrew Sullivan Filename : draft-ietf-precis-problem-statement-09.txt Pages : 29 Date : 2013-01-22 Abstract: If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode codepoints in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-problem-statement-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-problem-statement-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From marc.blanchet@viagenie.ca Tue Jan 22 08:35:14 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3BA21F8545 for ; Tue, 22 Jan 2013 08:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOfuIUSRDHnY for ; Tue, 22 Jan 2013 08:35:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFFF21F84E7 for ; Tue, 22 Jan 2013 08:35:13 -0800 (PST) Received: from h111.viagenie.ca (h111.viagenie.ca [206.123.31.111]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DD7644044D; Tue, 22 Jan 2013 11:35:11 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_605BCE47-E7B6-44EA-BEC7-D2FADEF6A2A3" Date: Tue, 22 Jan 2013 11:35:11 -0500 Message-Id: <1126F17F-2F02-499C-81C1-85AED0DE02FE@viagenie.ca> To: Pete Resnick Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-precis-problem-statement@tools.ietf.org, precis@ietf.org Subject: [precis] draft-ietf-precis-problem-statement revision X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:35:15 -0000 --Apple-Mail=_605BCE47-E7B6-44EA-BEC7-D2FADEF6A2A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear AD (and document shepherd), -09 just published should clear (or deny ;-) all comments made during = IESG review and IETF last call. Please note that none of the comments = were blocking. You find below the writeup with the comments and authors = response. diff with the previous version: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-precis-problem-statement-09 So to us, this document is ready for RFC queue. Marc and Andrew. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WRITEUP for draft-ietf-precis-problem-statement The following comments were received during IESG evaluation and IETF = calls and responses are included within . To note, of all of = the comments received, none were blocking, none were asking for = substantial changes. The shepherd writeup says this: Given that the document itself is informative, no normative references were appropriate and all of the references are informative. I think this is wrong. Normative references are those that are = necessary to the understanding of the document at hand, and they exist even for Informational documents. In this case, I think the following are = normative: Stringprep [RFC3454] IDNA Rationale [RFC5894] For the understanding of the document, it would require much more than = just RFC3454, 5894. It would also require Unicode understanding, internationalization terms understanding, = stringprep profiles, etc=85 To a point=20 where most references become normative. So we disagree and did not = include any separation of normative and non-normative. =20 You should probaby scrub this for consistent use of "Stringprep" (vs "stringprep"). done -- Section 1 -- In the list of known Stringprep uses, I would find it easier to read and = more convenient if items based on the same profile were grouped in = sub-bullets.=20 Something like this (significantly abbreviating here): o The Nameprep profile o IAX using Nameprep o NFSv4 and NFSv4.1 o The iSCSI profile o The Nodeprep and Resourceprep profiles o The SASLprep profile o IMAP4 using SASLprep o Plain SASL using SASLprep o NNTP using SASLprep o The LDAP profile o PKIX subject identification using LDAPprep o PKIX CRL using LDAPprep o The unicode-casemap Unicode Collation Then you can also note that in the following paragraph like this: NEW Moreover, many reuse the same Stringprep profile, such as the SASL one, as can be seen from the groupings above. Stringprep Profiles are not necessarily exactly using another = profile. They may (and do) have variations, such as exceptions on their base profile or usage. = Therefore, grouping might confuse the reader. The listing was made by RFC number ordering. We agree that a better = ordering would help reading. So we change the ordering to have the similar profiles all together.=20 OLD This algorithm is based on an inclusion-based approach NEW This algorithm uses an inclusion-based approach done -- Section 4 -- For example, Stringprep is based on and profiles may use NFKC [UAX15], while IDNA2008 mostly uses NFC [UAX15]. Because of the citations and because it's not central to what you're = saying, I don't think it's necessary to expand NFKC and NFC. But it might be = helpful to say something like, "for example, for normalization Stringprep [=85]" done a localpart which is similar to a username and used for authentication, a domainpart which is a domain name and a resource part which is less restrictive than the localpart. Because of the complexity of this and the imbedded "and" in the first = item, this list really demands the Oxford comma, "domain name, and". I'm not = sure the RFC Editor will get it right. done -- Section 5.2.6 -- Is "phishing" now a sufficiently common and lasting term that we can use = it without explanation? In any case, in the next sentence the issue *is* = to be considered (not "are"). done -- Section 7 -- To address the SecDir review comment, you might add something like this: = "See the Stringprep Security Considerations, [RFC3454] Sevtion 9. See also = the analyses in the subsections of Appendix B, below.' done - Why do you have a temporary WG name in the draft title? Who will = remember what PRECIS is in 10 years from now? Proposal: 1. either explain PRECIS = in the draft. At the very minimum the acronym. 2. Or remove PRECIS: Stringprep Revision Problem Statement 3. Alternatively, replace PRECIS: maybe = "Stringprep Revision and IDNA2008 Problem Statement" Acronym expanded - Why don't you refer to the latest version of the unicode, i.e. version = 6.2? The draft still refers to version 6.1. While 6.1 and 6.2 versions may not differ too much, 6.1 was the = one discussed during the work of this draft and given that this work has = a lot of dependencies on what Unicode does or not, it is preferable to = have the current Unicode version while the work was done to be the = referenced one. So we are keeping 6.1 as the reference. - You actually never explained what a (Stringprep) profile is, and what = it contains. For new comers who don't have the full IDNA background, a = couple of extra sentences would be welcome=85 Actually, there is a sentence or two on what a profile is. = Moreover, the Stringprep RFC is heavily referenced in the document. We = are not sure what else could be added without copying a large amount of = text from the Stringprep RFC, which is not really the purpose of the = document. So we decline this one. - What's the point to have a reference to [NEWPREP], since you don't = mention where they are? During IETF 77 (March 2010), a BOF discussed the current state of the protocols that have defined Stringprep profiles [NEWPREP]. [NEWPREP] "Newprep BoF Meeting Minutes", March 2010. For the interest of a reader, that BOF included various = presentations and meeting notes about the state of the protocols using = Stringprep profiles. Therefore, the intent of the reference is to point = the reader to additional context info useful for the understanding. The = reference points to the Meeting Minutes that can be retreived from the = IETF proceedings. The list of Known IETF Specifications in the introduction is presented = as a complete list. I believe it is already a little stale (see RFC6063 for example). Should the list be updated to those known specifications at = the time the RFC is published (and a datestamp added to qualify the statement), = or should the statement be softened to "Some known"? added "Some" as suggested. - 5.2.2 might have been a good place to explain what normalization means. You can sort of get it from the text, but might be nicer to add a definition. This comment also applies to other internationalization terms = used through the document. Normalization is defined more completly in = RFC6365 ("Terminology Used in Internationalization in the IETF". = Instead of copying multiple paragraphs, we added text and a reference = for the reader to 6365. Section 2 could be dropped as it isn't that important to have RFC 2119 in a problem statement. =20 The appendix that contains extracts of reviews and Stringprep = profiles RFC do contain RFC2119 keywords. So we are keeping this = section. In Section 4: "For example, Stringprep is based on and profiles may use NFKC [UAX15], while IDNA2008 mostly uses NFC [UAX15]." I suggest reviewing the references to see what background information is required for the reader to understand "NFKC". At the least, spelling out these acronyms on first use would be helpful (e.g., "Unicode Normalization Form KC"). we expanded the acronyms as suggested by the document = shepherd In Section 6: "The above suggests the following guidance for replacing Stringprep: o A stringprep replacement should be defined." That sounds obvious. rephrased. The appendix is more informative than the rest of the draft. The text in the Appendix B comes out as rough notes though. Indeed, that appendix consists of notes copied from a wiki page that the PRECIS WG used to collect the information. We agree with the document shepherd. no change to = draft In Section 5.3.3.2: "It is important to identify the willingness of the protocol-using=20 community to accept backwards-incompatible changes." The "tolerance for change" for several "protocol-using communities" is rated as "not sure". I understand that it is difficult to get=20 definitive answers for these questions. It's doubtful that people will choose "better support for different linguistic environments against the potential side effects of backward incompatibility". It seems that the WG has taken on an intractable problem. Your conclusion does not follow. Yes, it is true that we're not sure how willing some developer communities are to upgrade from Stringprep (based on Unicode 3.2) to PRECIS (version-agile, currently Unicode 6.1). However, we know that some developer communities are in fact willing to upgrade, and they have been more involved in the PRECIS WG. Furthermore, in general applications don't have a choice about what Unicode version is installed on the underlying system, so as time goes by Stringprep will become more and more problematic. There was strong agreement at the NEWPREP BoF to work on a common solution that all Stringprep-using protocols could re-use. The approach taken in the PRECIS framework specification is closely modelled on IDNA2008 and follows the recommendations from RFC 4690. If you are going to maintain that the PRECIS WG has taken on an intractable problem, then I think you're also arguing that the IDNABIS WG took on an intractable problem and that IDNA2008 failed to provide a viable solution to the shortcomings of IDNA2003 and the Nameprep profile of Stringprep. We agree with the document shepherd. no change to = draft --Apple-Mail=_605BCE47-E7B6-44EA-BEC7-D2FADEF6A2A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = AD (and document shepherd),
 -09 just published should clear = (or deny ;-) all comments made during IESG review and IETF last call. = Please note that none of the comments were blocking. You find below the = writeup with the comments and authors response.

 So to us, this document is = ready for RFC queue.

Marc and = Andrew.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
WRITEUP = for draft-ietf-precis-problem-statement

The following = comments were received during IESG evaluation and IETF calls and = responses are included within <AUTHORS>. To note, of all of the = comments received, none were blocking, none were asking for substantial = changes.

<COMMENT>
The shepherd writeup says = this:
  Given that the document itself is informative, no = normative
  references were appropriate and all of the = references are
  informative.

I think this is wrong. =  Normative references are those that are necessary to
the = understanding of the document at hand, and they exist even = for
Informational documents.  In this case, I think the = following are normative:
Stringprep [RFC3454] IDNA Rationale = [RFC5894]

<AUTHORS>
For the understanding of the = document, it would require much more than just RFC3454, 5894. It would = also
require Unicode understanding, internationalization terms = understanding, stringprep profiles, etc=85 To a point 
where = most references become normative. So we disagree and did not include any = separation of normative
and non-normative. =  
</AUTHORS>
</COMMENT>

<COMMENT>
Y= ou should probaby scrub this for consistent use of "Stringprep" = (vs
"stringprep").
<AUTHORS>done</AUTHORS>
</COMME= NT>

<COMMENT>
-- Section 1 --
In the list of known = Stringprep uses, I would find it easier to read and more
convenient = if items based on the same profile were grouped in = sub-bullets. 
Something like this (significantly abbreviating = here):

o  The Nameprep profile
  o  IAX = using Nameprep
o  NFSv4 and NFSv4.1
o  The iSCSI = profile
o  The Nodeprep and Resourceprep profiles
o  The = SASLprep profile
  o  IMAP4 using = SASLprep
  o  Plain SASL using = SASLprep
  o  NNTP using SASLprep
o  The LDAP = profile
  o  PKIX subject identification using = LDAPprep
  o  PKIX CRL using LDAPprep
o  The = unicode-casemap Unicode Collation

Then you can also note that in = the following paragraph like this:
NEW
  Moreover, many = reuse the same
  Stringprep profile, such as the SASL = one,
  as can be seen from the groupings = above.

<AUTHORS>Stringprep Profiles are not necessarily = exactly using another profile. They may (and do) have
variations, = such as exceptions on their base profile or usage. Therefore, grouping = might confuse the reader.
The listing was made by RFC number = ordering. We agree that a better ordering would help reading. So = we
 change the ordering to have the similar profiles all = together. 
</AUTHORS>
</COMMENT>

<COMMENT= >
OLD
  This algorithm is based
  on an = inclusion-based approach
NEW
  This algorithm = uses
  an inclusion-based = approach

<AUTHORS>done</AUTHORS>
</COMMENT>
<COMMENT>
-- Section 4 --
  For example, = Stringprep is based on and profiles may
  use NFKC [UAX15], = while IDNA2008 mostly uses NFC [UAX15].

Because of the citations = and because it's not central to what you're saying, I
don't think = it's necessary to expand NFKC and NFC.  But it might be helpful = to
say something like, "for example, for normalization Stringprep = [=85]"
<AUTHORS>done</AUTHORS>
</COMMENT>

&= lt;COMMENT>
  a localpart which is similar to a username = and used
  for authentication, a domainpart which is a = domain name and a
  resource part which is less restrictive = than the localpart.

Because of the complexity of this and the = imbedded "and" in the first item,
this list really demands the Oxford = comma, "domain name, and".  I'm not sure
the RFC Editor will get = it = right.
<AUTHORS>done</AUTHORS>
</COMMENT>

&= lt;COMMENT>
-- Section 5.2.6 --
Is "phishing" now a = sufficiently common and lasting term that we can use it
without = explanation?  In any case, in the next sentence the issue *is* to = be
considered (not = "are").
<AUTHORS>done</AUTHORS>
</COMMENT>

= <COMMENT>
-- Section 7 --
To address the SecDir review = comment, you might add something like this: "See
the Stringprep = Security Considerations, [RFC3454] Sevtion 9.  See also = the
analyses in the subsections of Appendix B, = below.'
<AUTHORS>done</AUTHORS>
</COMMENT>

= <COMMENT>
- Why do you have a temporary WG name in the draft = title? Who will remember
what PRECIS is in 10 years from now? = Proposal: 1. either explain PRECIS in the
draft. At the very minimum = the acronym. 2. Or remove PRECIS: Stringprep
Revision Problem = Statement 3. Alternatively, replace PRECIS: maybe = "Stringprep
Revision and IDNA2008 Problem = Statement"
<AUTHORS>Acronym = expanded</AUTHORS>
</COMMENT>


<COMMENT>- Why don't you refer to the latest version of the unicode, i.e. = version 6.2?
The draft still refers to version = 6.1.
<AUTHORS>While 6.1 and 6.2 versions may not differ too = much, 6.1 was the one discussed during the work of this draft and given = that this work has a lot of dependencies on what Unicode does or not, it = is preferable to have the current Unicode version while the work was = done to be the referenced one. So we are keeping 6.1 as the = reference.</AUTHORS>
</COMMENT>


<COMMENT><= br>- You actually never explained what a (Stringprep) profile is, and = what it
contains. For new comers who don't have the full IDNA = background, a couple of
extra sentences would be = welcome=85
<AUTHORS>Actually, there is a sentence or two on = what a profile is. Moreover, the Stringprep RFC is heavily referenced in = the document.  We are not sure what else could be added without = copying a large amount of text from the Stringprep RFC, which is not = really the purpose of the document. So we decline this = one.</AUTHORS>
</COMMENT>

<COMMENT>
- = What's the point to have a reference to [NEWPREP], since you don't = mention
where they are?

 During IETF 77 (March 2010), a = BOF discussed the current state of the
  protocols that = have defined Stringprep profiles [NEWPREP].

  [NEWPREP] =  "Newprep BoF Meeting Minutes", March 2010.
<AUTHORS>For = the interest of a reader, that BOF included various presentations and = meeting notes about the state of the protocols using Stringprep = profiles. Therefore, the intent of the reference is to point the reader = to additional context info useful for the understanding.  The = reference points to the Meeting Minutes that can be retreived from the = IETF proceedings.
</COMMENT>

<COMMENT>
The list = of Known IETF Specifications in the introduction is presented as = a
complete list. I believe it is already a little stale (see RFC6063 = for
example). Should the list be updated to those known = specifications at the time
the RFC is published (and a datestamp = added to qualify the statement), or
should the statement be softened = to "Some known"?
<AUTHORS>added "Some" as = suggested.</AUTHORS>
</COMMENT>

<COMMENT>
-= 5.2.2 might have been a good place to explain what
normalization = means. You can sort of get it from the
text, but might be nicer to = add a definition.
<AUTHORS>This comment also applies to other = internationalization terms used through the document. Normalization is = defined more completly in RFC6365 ("Terminology Used in = Internationalization in the IETF".  Instead of copying multiple = paragraphs, we added text and a reference for the reader to = 6365.</AUTHORS>
</COMMENT>


<COMMENT>
Se= ction 2 could be dropped as it isn't that important to have RFC
2119 = in a problem statement.  

<AUTHORS>The appendix that = contains extracts of reviews and Stringprep profiles RFC do contain = RFC2119 keywords. So we are keeping this = section.</AUTHORS>
</COMMENT>

<COMMENT>
In = Section 4:

"For example, Stringprep is based on and profiles may = use NFKC
[UAX15], while IDNA2008 mostly uses NFC [UAX15]."
I = suggest reviewing the references to see what background
information = is required for the reader to understand "NFKC".

<document = shepherd suggestion>
At the least, spelling out these acronyms on = first use would be
helpful (e.g., "Unicode Normalization Form = KC").
</document shepherd suggestion>

<AUTHORS>we = expanded the acronyms as suggested by the document = shepherd</AUTHORS>
</COMMENT>

<COMMENT>
In = Section 6:

"The above suggests the following guidance for = replacing
Stringprep: o  A stringprep replacement should be = defined."

That sounds = obvious.
<AUTHORS>rephrased.</AUTHORS>
</COMMENT><= br>
<COMMENT>
The appendix is more informative than the rest = of the draft.  The
text in the Appendix B comes out as rough = notes though.

<document shepherd response>
Indeed, that = appendix consists of notes copied from a wiki page that
the PRECIS WG = used to collect the information.
</document shepherd = response>
<AUTHORS>We agree with the document shepherd. no = change to = draft</AUTHORS>
</COMMENT>

<COMMENT>
In = Section 5.3.3.2:

"It is important to identify the willingness of = the protocol-using 
community to accept backwards-incompatible = changes."

The "tolerance for change" for several "protocol-using = communities"
is rated as "not sure".  I understand that it is = difficult to get 
definitive answers for these questions. =  It's doubtful that people
will choose "better support for = different linguistic environments
against the potential side effects = of backward incompatibility".
It seems that the WG has taken on an = intractable problem.

<document shepherd response>
Your = conclusion does not follow. Yes, it is true that we're not sure
how = willing some developer communities are to upgrade from = Stringprep
(based on Unicode 3.2) to PRECIS (version-agile, currently = Unicode
6.1). However, we know that some developer communities are in = fact
willing to upgrade, and they have been more involved in the = PRECIS WG.
Furthermore, in general applications don't have a choice = about what
Unicode version is installed on the underlying system, so = as time goes
by Stringprep will become more and more problematic. = There was strong
agreement at the NEWPREP BoF to work on a common = solution that all
Stringprep-using protocols could re-use. The = approach taken in the
PRECIS framework specification is closely = modelled on IDNA2008 and
follows the recommendations from RFC 4690. = If you are going to
maintain that the PRECIS WG has taken on an = intractable problem, then
I think you're also arguing that the = IDNABIS WG took on an intractable
problem and that IDNA2008 failed to = provide a viable solution to the
shortcomings of IDNA2003 and the = Nameprep profile of Stringprep.
</document shepherd = response>
<AUTHORS>We agree with the document shepherd. no = change to = draft</AUTHORS>
</COMMENT>

= --Apple-Mail=_605BCE47-E7B6-44EA-BEC7-D2FADEF6A2A3-- From stpeter@stpeter.im Tue Jan 22 08:41:49 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F7021F8A5A for ; Tue, 22 Jan 2013 08:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfoA56oPGgeb for ; Tue, 22 Jan 2013 08:41:47 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB14921F8A6C for ; Tue, 22 Jan 2013 08:41:47 -0800 (PST) Received: from [10.129.24.64] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2C83040049; Tue, 22 Jan 2013 09:47:40 -0700 (MST) Message-ID: <50FEC14E.7050901@stpeter.im> Date: Tue, 22 Jan 2013 09:41:50 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Marc Blanchet References: <1126F17F-2F02-499C-81C1-85AED0DE02FE@viagenie.ca> In-Reply-To: <1126F17F-2F02-499C-81C1-85AED0DE02FE@viagenie.ca> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , draft-ietf-precis-problem-statement@tools.ietf.org, precis@ietf.org Subject: Re: [precis] draft-ietf-precis-problem-statement revision X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:41:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/22/13 9:35 AM, Marc Blanchet wrote: > Dear AD (and document shepherd), -09 just published should clear > (or deny ;-) all comments made during IESG review and IETF last > call. Please note that none of the comments were blocking. You find > below the writeup with the comments and authors response. diff with > the previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-problem-statement-09 I > reviewed the diff and it looked fine to me. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlD+wU4ACgkQNL8k5A2w/vz1jwCgrHkboT7SS90hgnPB6ORqOle4 oFMAoL5PEDJB53z13Nni7c5MjBDqOsm1 =Ocxs -----END PGP SIGNATURE----- From iesg-secretary@ietf.org Tue Jan 22 09:01:13 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9F221F8A3E; Tue, 22 Jan 2013 09:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmQ4F7mjDYQY; Tue, 22 Jan 2013 09:01:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27BC21F8A84; Tue, 22 Jan 2013 09:01:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122170109.31381.46336.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 09:01:09 -0800 Cc: precis chair , precis mailing list , RFC Editor Subject: [precis] Document Action: 'Stringprep Revision and PRECIS Problem Statement' to Informational RFC (draft-ietf-precis-problem-statement-09.txt) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:01:13 -0000 The IESG has approved the following document: - 'Stringprep Revision and PRECIS Problem Statement' (draft-ietf-precis-problem-statement-09.txt) as Informational RFC This document is the product of the Preparation and Comparison of Internationalized Strings Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement/ Technical Summary If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode codepoints in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. Working Group Summary The document records the consensus from discussion at the NEWPREP BoF (IETF 77, March 2010) and the resulting PRECIS WG regarding the problem to be solved in developing a replacement for the Stringprep technology in application protocols other than IDNA. There has not been controversy about the nature of the problem to be solved, and consensus was not rough. Document Quality The document has provided a clear basis for work on the proposed PRECIS framework, and thus has served its purpose. Personnel The Document Shepherd is Peter Saint-Andre. The Responsible Area Director is Pete Resnick. From marc.blanchet@viagenie.ca Wed Jan 23 06:18:22 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172DF21F855C for ; Wed, 23 Jan 2013 06:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY15a2gPLJhd for ; Wed, 23 Jan 2013 06:18:21 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7711C21F8439 for ; Wed, 23 Jan 2013 06:18:21 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E8E2D40435 for ; Wed, 23 Jan 2013 09:18:20 -0500 (EST) From: Marc Blanchet Content-Type: multipart/alternative; boundary="Apple-Mail=_F2194FFC-364C-42F0-91A7-377B7D6389F8" Date: Wed, 23 Jan 2013 09:18:20 -0500 References: <20130123135629.14736.8296.idtracker@ietfa.amsl.com> To: precis@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [precis] Fwd: ID Tracker State Update Notice: X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 14:18:22 -0000 --Apple-Mail=_F2194FFC-364C-42F0-91A7-377B7D6389F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 now the problem statement in the RFC editor queue! One almost done! = congrats to everybody who contributed, especially the reviewers of the = stringprep profiles. Marc. D=E9but du message r=E9exp=E9di=E9 : > De : IETF Secretariat > Objet : ID Tracker State Update Notice: = > Date : 23 janvier 2013 08:56:29 HNE > Renvoy=E9-=C0 : asullivan@dyn.com, marc.blanchet@viagenie.ca > Renvoy=E9-=C0 : Marc.Blanchet@viagenie.ca, yoshiro.yoneya@jprs.co.jp, > =C0 : precis-chairs@tools.ietf.org, = draft-ietf-precis-problem-statement@tools.ietf.org, stpeter@stpeter.im >=20 > State changed to RFC Ed Queue from Approved-announcement sent > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement/ --Apple-Mail=_F2194FFC-364C-42F0-91A7-377B7D6389F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 now = the problem statement in the RFC editor queue!  One almost done! = congrats to everybody who contributed, especially the reviewers of the = stringprep profiles.

Marc.

D=E9but = du message r=E9exp=E9di=E9 :

De : IETF Secretariat = <ietf-secretariat-reply@iet= f.org>
Objet : ID Tracker State Update Notice: = <draft-ietf-precis-problem-statement-09.txt>
Date : 23 janvier 2013 = 08:56:29 HNE
=
State changed to RFC Ed Queue from Approved-announcement = sent
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement/

= --Apple-Mail=_F2194FFC-364C-42F0-91A7-377B7D6389F8-- From stpeter@stpeter.im Thu Jan 24 14:33:53 2013 Return-Path: X-Original-To: precis@ietfa.amsl.com Delivered-To: precis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C6911E80BF for ; Thu, 24 Jan 2013 14:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DdMKQ3TDQZm for ; Thu, 24 Jan 2013 14:33:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 56EF211E8099 for ; Thu, 24 Jan 2013 14:33:49 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D40FF40564 for ; Thu, 24 Jan 2013 15:39:48 -0700 (MST) Message-ID: <5101B6D3.1080500@stpeter.im> Date: Thu, 24 Jan 2013 15:33:55 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "precis@ietf.org" References: <20130124221616.8046.25893.idtracker@ietfa.amsl.com> In-Reply-To: <20130124221616.8046.25893.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130124221616.8046.25893.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [precis] Fwd: [Simple] Protocol Action: 'Multi-party Chat Using the Message Session Relay Protocol (MSRP)' to Proposed Standard (draft-ietf-simple-chat-18.txt) X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 22:33:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. This spec has a normative dependency on the precis-nickname I-D. :-) Peter - -------- Original Message -------- Subject: [Simple] Protocol Action: 'Multi-party Chat Using the Message Session Relay Protocol (MSRP)' to Proposed Standard (draft-ietf-simple-chat-18.txt) Date: Thu, 24 Jan 2013 14:16:16 -0800 From: The IESG To: IETF-Announce CC: simple chair , simple mailing list , RFC Editor The IESG has approved the following document: - - 'Multi-party Chat Using the Message Session Relay Protocol (MSRP)' (draft-ietf-simple-chat-18.txt) as Proposed Standard This document is the product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-simple-chat/ Technical Summary The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. Working Group Summary There has been controversy about doing this work in SIMPLE. The XCON working group was chartered to do create similar mechanisms in a media independent fashion. There was a compromise consensus to do this draft in SIMPLE with the idea that, with its smaller scope, it could complete more quickly than the XCON work, and that it would be a short-term solution until XCON completed the more general work. This in fact did not occur, as this draft took longer than expected due to several editor changes. Discussion at the SIMPLE meeting at IETF75 concluded that we should capture the parts of this draft were specific about mixing MSRP at a conference bridge, but abandon the rest in favor of XCON. However, this conclusion did not achieve consensus when brought it to the working group list at large. We readdressed this on the SIMPLE list in September 2010. A few participants strongly argued that the work should be abandoned, as it conflicted with (now substantially complete) work in XCON. But others (including at least one implementor) argued for completion. In particular, several people argued that this draft enabled them to build a light weight text-chat service without requiring all the features enabled by XCON. Note that the XCON working group has since completed its work and closed. In summary, the working group originally had a consensus to complete this work, and has not achieved a consensus to change that plan. We had agreement to pubreq version 07 in late 2010. The shepherd found some issues during the PROTO review. The work group discussed the substantive changes since version 07 on list, and we had a similar consensus to pubreq version 11 without a new WGLC The apps area review turned up some issues with the internationalization of nicknames. The related updates, as well as a new normative dependency on the PRECIS work, have been vetted on the SIMPLE list. Document Quality. The document has quite a bit of review over its lifespan in the SIMPLE work group. It lists Eva Leppanen, Adamu Haruna, Adam Roach, Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrianv Georgescu, and Nancy Greene as reviewers in the acknowledgments. The document has undergone an MMUSIC expert review (Flemming Andreasen), since it contains an SDP extension. It has been through WGLC, multiple consensus calls, as well as an IETF last call. It has had 2 Gen-ART reviews (Christer Holmberg as Suresh Krishnan) , as well as IANA, apps-dir (Alexey Melnikov), tsv-dir (Cullen Jennings), and sec-dir (Vincent Roca) reviews. The shepherd believes that all issues raised in these reviews have been resolved. There are at least two existing implementations, "Blink" as a client and "SylkServer" as a server. A few others have indicated the intent to implement it. Additionally, the GSMA RCS 5.1 specification references this document in order to use the a=chatroom attribute. Personnel The document shepherd for this document is Ben Campbell. The responsible Area Director is Robert Sparks. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEBttMACgkQNL8k5A2w/vxmcACeLoMygGOwUEkNO/epdSBQAbEq 11wAoI/mqKjTaQ9vcyyCcyssxEiWzdNK =UHFV -----END PGP SIGNATURE-----