PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
draft-ietf-precis-framework-23
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-05-14
|
23 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-05-12
|
23 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-05-07
|
23 | (System) | RFC Editor state changed to RFC-EDITOR from MISSREF |
2015-04-10
|
23 | (System) | RFC Editor state changed to MISSREF from AUTH |
2015-04-10
|
23 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-04-09
|
23 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2015-04-09
|
23 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2015-04-02
|
23 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-03-23
|
23 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-03-11
|
23 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2015-03-06
|
23 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-03-06
|
23 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2015-02-24
|
23 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-02-23
|
23 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-02-23
|
23 | (System) | RFC Editor state changed to EDIT |
2015-02-23
|
23 | (System) | Announcement was received by RFC Editor |
2015-02-23
|
23 | (System) | IANA Action state changed to In Progress |
2015-02-23
|
23 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-02-23
|
23 | Amy Vezza | IESG has approved the document |
2015-02-23
|
23 | Amy Vezza | Closed "Approve" ballot |
2015-02-23
|
23 | Amy Vezza | Ballot approval text was generated |
2015-02-20
|
23 | Pete Resnick | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2015-02-19
|
23 | Pete Resnick | Ballot writeup was changed |
2015-02-19
|
23 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-02-19
|
23 | Peter Saint-Andre | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-02-19
|
23 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-23.txt |
2015-02-19
|
22 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Waiting for AD Go-Ahead |
2015-02-19
|
22 | Stephen Farrell | [Ballot comment] Last time this came around I had the comments below. While Barry no longer has a DISCUSS, I'd still be interested in chatting … [Ballot comment] Last time this came around I had the comments below. While Barry no longer has a DISCUSS, I'd still be interested in chatting a bit about these. (Apologies that I've not had time to re-read the draft though, so feel free to just tell me these comments are OBE if that's the case.) " - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-) " |
2015-02-19
|
22 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-02-19
|
22 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-02-19
|
22 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-02-19
|
22 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-02-19
|
22 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-02-19
|
22 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-02-18
|
22 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-02-18
|
22 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2015-02-18
|
22 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-02-18
|
22 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft, it reads very well! Thanks for addressing the prior SecDir review comments: https://www.ietf.org/mail-archive/web/secdir/current/msg04732.html |
2015-02-18
|
22 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-02-17
|
22 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-02-17
|
22 | Spencer Dawkins | [Ballot comment] A nit: b. Comparing two output strings to determine if they equivalent, … [Ballot comment] A nit: b. Comparing two output strings to determine if they equivalent, ^are typically through octet-for-octet matching to test for "bit- string identity" (e.g., to make an access decision for purposes of authentication or authorization as further described in [RFC6943]). |
2015-02-17
|
22 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-02-17
|
22 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2015-02-16
|
22 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-02-16
|
22 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-precis-framework-22. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-precis-framework-22. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments: IANA understands that, upon approval of this document, the authors request the creation of three registries in support of the PRECIS Framework. As far as IANA can tell, there have never been registries created for PRECIS in the past. In consultation with the authors, IANA understands that there will be a new PRECIS-specific master registry created on the IANA Matrix to hold the three registries described below. First, IANA will create a new registry called the PRECIS Derived Property Value Registry. This new registry will contain the Derived Properties for the versions of Unicode that are released after (and including) version 7.0 of Unicode. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the rules specified under Section 8 and Section 9 in the current document. The registry will only be created when a designated expert is made available to assist IANA in the initiation of the registry. Changes to the rules that are used to generate the table of derived property values, and thus the registry itself, are done through IETF Review as defined by RFC 5226. IANA understands that this new registry will have no initial values when it is first established. Second, IANA will create a new registry called the PRECIS Base Classes Registry. This new registry has a registration template in the document submitted for approval. Maintenance of the registry will be through RFC Required, as defined in RFC 5226. There are two initial registrations in the registry, as follows: Base Class: FreeformClass. Description: A sequence of letters, numbers, symbols, spaces, and other code points that is used for free-form strings. Specification: Section 4.3 of [ RFC-to-be ]. Base Class: IdentifierClass. Description: A sequence of letters, numbers, and symbols that is used to identify or address a network entity. Specification: Section 4.2 of [ RFC-to-be ]. Third, IANA will create a new registry called the PRECIS Profiles Registry. This new registry has a registration template in the document submitted for approval. Maintenance of the registry will be through Expert Review, as defined in RFC 5226. In consultation with the authors, IANA understands that the new registry will have no initial values when it is first established. IANA understands that these three actions are the only ones that need to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. |
2015-02-16
|
22 | Pete Resnick | Note added 'Please be aware of the note in the ballot, especially regarding the IAB Statement.' |
2015-02-16
|
22 | Pete Resnick | Ballot has been issued |
2015-02-16
|
22 | Pete Resnick | Ballot writeup was changed |
2015-02-09
|
22 | Pete Resnick | Ballot has been issued |
2015-02-09
|
22 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2015-02-09
|
22 | Amy Vezza | Telechat date has been changed to 2015-02-19 from 2014-04-24 |
2015-02-09
|
22 | Amy Vezza | Created "Approve" ballot |
2015-02-09
|
22 | Amy Vezza | Closed "Approve" ballot |
2015-02-08
|
22 | Pete Resnick | Ballot writeup was changed |
2015-02-08
|
22 | Pete Resnick | Ballot writeup was changed |
2015-02-08
|
22 | Pete Resnick | Ballot writeup was changed |
2015-02-05
|
22 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (PRECIS Framework: Preparation, Enforcement, and … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard The IESG has received a request from the Preparation and Comparison of Internationalized Strings WG (precis) to consider the following document: - 'PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols' as Proposed Standard This is a second Last Call. Even though this document has already been through IESG Evaluation and was approved pending an RFC Editor note to address some comments, significant enough issues were raised and changes were made that a new Last Call and IESG Evaluation is prudent. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-02-05
|
22 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-02-05
|
22 | Pete Resnick | Last call was requested |
2015-02-05
|
22 | Pete Resnick | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-02-05
|
22 | Pete Resnick | Last call announcement was changed |
2015-02-05
|
22 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-02-05
|
22 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-22.txt |
2015-02-04
|
21 | Pete Resnick | Last call announcement was changed |
2015-02-04
|
21 | Pete Resnick | Last call announcement was generated |
2015-02-04
|
21 | Pete Resnick | Going back into Last Call. Waiting for a conclusion to discussion about what to say regarding the IAB Statement. |
2015-02-04
|
21 | Pete Resnick | IESG state changed to AD Evaluation::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2014-12-10
|
21 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-21.txt |
2014-11-28
|
20 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2014-11-28
|
20 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2014-11-21
|
20 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-20.txt |
2014-10-23
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-10-23
|
19 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-19.txt |
2014-09-22
|
18 | Pete Resnick | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup |
2014-09-02
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-09-02
|
18 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-18.txt |
2014-07-31
|
17 | Pete Resnick | Waiting for text to address concerns raised by John Klensin after Last Call. |
2014-07-31
|
17 | Pete Resnick | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::Point Raised - writeup needed |
2014-05-27
|
17 | Peter Saint-Andre | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2014-05-27
|
17 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-17.txt |
2014-05-03
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tim Wicinski. |
2014-04-24
|
16 | (System) | Requested Last Call review by GENART |
2014-04-24
|
16 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2014-04-24
|
16 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Charlie Kaufman. |
2014-04-24
|
16 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-04-24
|
16 | Barry Leiba | [Ballot comment] After discussion, I'm moving this to a non-blocking comment. I still think that the working group and the responsible AD did not handle … [Ballot comment] After discussion, I'm moving this to a non-blocking comment. I still think that the working group and the responsible AD did not handle this right, and strongly urge not repeating this mechanism in future. The registry created in Section 9.1 is very odd indeed. I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be. In the IANA review, it's clear that they're not sure what's going to happen here. But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately. Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry. It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely. Why was it done this way, and what is the plan to get the registry content specified in a reasonable time? Should approval of the document wait for that content to be specified? Or are we really expecting to approve the document with the content of the registry left open? UPDATE AFTER DISCUSSION: The response to my final questions says that IDNAbis did it this way, the intent is to use the same expert as for that registry, and it's not expected to be terribly burdensome. It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document. The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert. That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture. When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again. It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now. As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed. |
2014-04-24
|
16 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to Yes from Discuss |
2014-04-24
|
16 | Stephen Farrell | [Ballot comment] - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being … [Ballot comment] - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-) |
2014-04-24
|
16 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-04-24
|
16 | Benoît Claise | [Ballot comment] - More of a series of question than a COMMENT. Disclaimer: the PRECIS work is very far from my comfort zone, so there … [Ballot comment] - More of a series of question than a COMMENT. Disclaimer: the PRECIS work is very far from my comfort zone, so there might be a little bit of eduction involved here. You have identified IdentifierClass and FreeformClass. As OPS AD, I'm wondering whether future OPS data models should take these classes into account. Let me explain. We have: SMI Textual Convention (RFC 2579). For example: SnmpAdminString YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3) IPFIX data types (RFC 7011) AAA Should we ideally start specifying our data model strings according to these classes, to facilitate strings comparison operations? Should we start defining new SMI TC, YANG typedef, or IPFIX data types? Is there some education required in OPS? I guess that there is no action for the authors at this point, and the next step is an informal discussion with Pete. - https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/ There is a normative downref to draft-ietf-precis-mappings (an Informative document). I see that draft-ietf-precis-mappings in the informative references. |
2014-04-24
|
16 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-04-23
|
16 | Pete Resnick | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-04-23
|
16 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-04-23
|
16 | Barry Leiba | [Ballot discuss] I will move to a strong "yes" on this, once we have some discussion of the registry defined in Section 9.1. The registry … [Ballot discuss] I will move to a strong "yes" on this, once we have some discussion of the registry defined in Section 9.1. The registry created in Section 9.1 is very odd indeed. I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be. In general, I see that IANA has asked several questions in its review, and those questions haven't been responded to (and, unusually, the IANA review is in the IESG mailing list archive but *not* in the document history in the datatracker). They should be given a response. But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately. Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry. It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely. Why was it done this way, and what is the plan to get the registry content specified in a reasonable time? Should approval of the document wait for that content to be specified? Or are we really expecting to approve the document with the content of the registry left open? |
2014-04-23
|
16 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2014-04-23
|
16 | Ted Lemon | [Ballot comment] In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to … [Ballot comment] In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to later references in section 7. Aside from that, this is an excellent attempt to provide a basis for unraveling the gordian knot of unicode use in standards, and I look forward to seeing how it works in practice. |
2014-04-23
|
16 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-04-23
|
16 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-04-23
|
16 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-04-23
|
16 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-04-23
|
16 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-04-22
|
16 | Kathleen Moriarty | [Ballot comment] Thanks for addressing the SecDir comments so quickly! |
2014-04-22
|
16 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-04-22
|
16 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2014-04-22
|
16 | Adrian Farrel | [Ballot comment] Not my area of expertise, but ... :-) Why isn't BCP18 an important reference? |
2014-04-22
|
16 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-04-21
|
16 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-16.txt |
2014-04-21
|
15 | Alissa Cooper | [Ballot comment] Nice work. I have one comment in Section 4.3, which says: One consequence of disallowing space characters in the IdentifierClass might be … [Ballot comment] Nice work. I have one comment in Section 4.3, which says: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or, even more problematically, non-ASCII space characters) within identifiers created in newer application protocols; given the challenges involved in properly handling space characters in identifiers and other protocol strings, the Working Group considered this to be a feature, not a bug. I find the use of the phrase “even more problematically” confusing given that it comes after “to effectively discourage.” I think the intended meaning here is that if non-ASCII space characters were to be used (or _encouraged_), that would be even more problematic than if ASCII space characters were to be used (or encouraged), right? I would suggest the following edit to the first part of the first sentence: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or the even more problematic non-ASCII space characters) within identifiers created in newer application protocols; |
2014-04-21
|
15 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-04-20
|
15 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-04-18
|
15 | Pete Resnick | [Ballot comment] The following are all items I mentioned in my AD Eval, but we decided none was a show-stopper and all could be held … [Ballot comment] The following are all items I mentioned in my AD Eval, but we decided none was a show-stopper and all could be held until the end of Last Call. The only substantive point is on 4.1.5, and the world will not end if I end up in the rough on this point. (We don't expect a whole lot of feedback during Last Call; the document got a good deal of review by a lot of experts, but the topic is pretty esoteric for anyone else to have much of a strong opinion.) Throughout: Change "Informational Note:" to "Note:". I don't see any of them for which it makes a difference. 3.1: I would move the first paragraph down further in the section. And I would delete the parenthetical at the end of "Contextual Rule Required"; no need to introduce undefined terms here. 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that a string with a Disallowed character "SHALL be rejected". If it were me, I'd simply say: Any code points that are not yet designated in the Unicode character set are considered Unassigned for purposes of the XXXClass, and such code points are to be treated as Disallowed. 4.1: Change "MUST register" to "are registered". MUSTs for registration seem silly. (If you want to say, "Implementations MUST NOT use unregistered classes", you could, but I don't think you want to do that.) Change "It is RECOMMENDED for profile names to be of the form" to "The naming convention for profile names is to use the form". 4.1.5: I'm not thrilled with this section in general, but in particular I'm not sure what "mixed-direction strings are not supported" means. We do know how to process strings that contain characters with a mix of directionality. Such strings are sometimes a visual challenge, but not a processing challenge: The RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an LTR or RTL context, and because IDNs use "." as a label separator yet want to have text display consistent in a context that is unaware of labels. There are perfectly reasonable cases where none of these hold true, so I think this section could be softened so that it's not overtly pushing that protocols never allow mixed direction text or that they should always lean toward using RFC 5893. 4.2: A bit of ABNF neatening: OLD fullname = namepart [1*(1*SP namepart)] namepart = 1*(idpoint) NEW fullname = namepart *(1*SP namepart) namepart = 1*idpoint 9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations for IdentifierClass and FreeformClass. 9.3: It might be nice to note the naming convention from 4.1 in the template. |
2014-04-18
|
15 | Pete Resnick | Ballot comment text updated for Pete Resnick |
2014-04-18
|
15 | Pete Resnick | Notification list changed to : precis-chairs@tools.ietf.org, draft-ietf-precis-framework@tools.ietf.org, precis@ietf.org |
2014-04-18
|
15 | Pete Resnick | Ballot has been issued |
2014-04-18
|
15 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2014-04-18
|
15 | Pete Resnick | Created "Approve" ballot |
2014-04-18
|
15 | Pete Resnick | Ballot writeup was changed |
2014-04-14
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2014-04-14
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2014-04-10
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tom Taylor |
2014-04-10
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Tom Taylor |
2014-04-10
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
2014-04-10
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
2014-04-09
|
15 | Pete Resnick | Placed on agenda for telechat - 2014-04-24 |
2014-04-09
|
15 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-04-09
|
15 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (PRECIS Framework: Preparation and Comparison … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard The IESG has received a request from the Preparation and Comparison of Internationalized Strings WG (precis) to consider the following document: - 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454. This document makes a normative reference to RFC 20, which predates document statuses and therefore may be a downward reference. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-04-09
|
15 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-04-09
|
15 | Amy Vezza | Last call announcement was changed |
2014-04-08
|
15 | Pete Resnick | Ballot writeup was changed |
2014-04-08
|
15 | Pete Resnick | Last call was requested |
2014-04-08
|
15 | Pete Resnick | Ballot approval text was generated |
2014-04-08
|
15 | Pete Resnick | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2014-04-08
|
15 | Pete Resnick | Last call announcement was changed |
2014-04-08
|
15 | Pete Resnick | Last call announcement was generated |
2014-04-08
|
15 | Pete Resnick | Last call announcement was generated |
2014-04-07
|
15 | Pete Resnick | Waiting 24 hours to confirm that the WG is OK with Last Call. |
2014-04-07
|
15 | Pete Resnick | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
2014-03-14
|
15 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-15.txt |
2014-02-26
|
14 | Pete Resnick | IESG state changed to AD Evaluation from Publication Requested |
2014-02-19
|
14 | Pete Resnick | Changed consensus to Yes from Unknown |
2014-02-13
|
14 | Yoshiro Yoneya | 1. Summary The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. Application protocols using Unicode characters in protocol strings need to … 1. Summary The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. This document obsoletes RFC 3454. The document is suitable for Standard Track. 2. Review and Consensus The approach used by the document is similar to IDNA 2008 approach (use of Unicode character properties for deciding what to do with characters) and thus wasn't controversial. The WG spent some time deciding how many classes need to be defined and what kind of class is suitable for "profiling" for different purposes. In particular the discussion of use of spaces in Identifier class took a bit of time. But the WG converged at the end. 3. Intellectual Property Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. 4. Other Points There is a normative downref to draft-ietf-precis-mappings (an Informative document). ID-Nits also complains a normative reference to RFC 20, because the RFC status is not known. |
2014-02-13
|
14 | Yoshiro Yoneya | Working group state set to Submitted to IESG for Publication |
2014-02-13
|
14 | Yoshiro Yoneya | IETF WG state changed to Submitted to IESG for Publication |
2014-02-13
|
14 | Yoshiro Yoneya | IESG state changed to Publication Requested |
2014-02-13
|
14 | Yoshiro Yoneya | IESG state set to Publication Requested |
2014-02-10
|
14 | Alexey Melnikov | 1. Summary The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. Application protocols using Unicode characters in protocol strings need to … 1. Summary The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. This document obsoletes RFC 3454. The document is suitable for Standard Track. 2. Review and Consensus The approach used by the document is similar to IDNA 2008 approach (use of Unicode character properties for deciding what to do with characters) and thus wasn't controversial. The WG spent some time deciding how many classes need to be defined and what kind of class is suitable for "profiling" for different purposes. In particular the discussion of use of spaces in Identifier class took a bit of time. But the WG converged at the end. 3. Intellectual Property Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. 4. Other Points There is a normative downref to draft-ietf-precis-mappings (an Informative document). ID-Nits also complains a normative reference to RFC 20, because the RFC status is not known. |
2014-02-10
|
14 | Marc Blanchet | New version available: draft-ietf-precis-framework-14.txt |
2013-12-05
|
13 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-13.txt |
2013-11-21
|
12 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-12.txt |
2013-10-18
|
11 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-11.txt |
2013-10-15
|
10 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-10.txt |
2013-08-27
|
09 | Yoshiro Yoneya | IETF WG state changed to In WG Last Call from WG Document |
2013-08-01
|
09 | Marc Blanchet | Document shepherd changed to Alexey Melnikov |
2013-07-10
|
09 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-09.txt |
2013-04-25
|
08 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-08.txt |
2013-03-26
|
07 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-07.txt |
2013-02-14
|
06 | Pete Resnick | Ballot writeup was generated |
2012-09-23
|
06 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-06.txt |
2012-08-01
|
05 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-05.txt |
2012-07-16
|
04 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-04.txt |
2012-05-10
|
03 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-03.txt |
2012-03-12
|
02 | Peter Saint-Andre | New version available: draft-ietf-precis-framework-02.txt |
2011-10-30
|
01 | (System) | New version available: draft-ietf-precis-framework-01.txt |
2011-10-04
|
01 | Pete Resnick | Draft added in state AD is watching |
2011-10-04
|
01 | Pete Resnick | Earlier history may be found in the Comment Log for draft-blanchet-precis-framework |
2011-08-22
|
00 | (System) | New version available: draft-ietf-precis-framework-00.txt |