From f87a105f11451142e6cb688b43c0c8eb7e0bc1df Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 6 Mar 2003 20:03:24 +0000 Subject: [PATCH] Remove. --- draft-ietf-ips-iscsi-string-prep-03.txt | 451 -------------------------------- draft-ietf-krb-wg-utf8-profile-00.txt | 399 ---------------------------- 2 files changed, 850 deletions(-) delete mode 100644 draft-ietf-ips-iscsi-string-prep-03.txt delete mode 100644 draft-ietf-krb-wg-utf8-profile-00.txt diff --git a/draft-ietf-ips-iscsi-string-prep-03.txt b/draft-ietf-ips-iscsi-string-prep-03.txt deleted file mode 100644 index b93be15..0000000 --- a/draft-ietf-ips-iscsi-string-prep-03.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Internet Draft Mark Bakke - Cisco -Standards Track -Expires April 2003 - -October 2002 - - - String Profile for iSCSI Names - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - The iSCSI protocol provides a way for hosts to access SCSI devices - over an IP network. The iSCSI end-points, called initiators and - targets, each have a globally-unique name that must be transcribable, - as well as easily compared. - - This document describes how to prepare internationlized iSCSI names - to increase the likelihood that name input and comparison work in - ways that make sense for typical users throughout the world. - - - - -Bakke Expires April 2003 [Page 1] - -Internet Draft String Profile for iSCSI Names October 2002 - - -Acknowledgements - - This draft was produced as a result of discussions on iSCSI name - formats with Joe Czap, Jim Hafner, Howard Hall, Jack Harwood, John - Hufferd, Marjorie Krueger, Lawrence Lamers, Todd Sperry, Joshua - Tseng, and Kaladhar Voruganti, as well as discussions on the - normalization of names into identifiers with Paul Hoffman and Marc - Blanchet. - - Thanks also to Bob Snively for suggesting the use of the nameprep - process for iSCSI name normalization. - - Most of this draft was copied from the stringprep profile for - nameprep [NAMEPREP], written by Paul Hoffman and Marc Blanchet. - - -1. Introduction - - The iSCSI protocol [ISCSI] provides a way for hosts to access SCSI - [SAM2] devices over an IP network. The iSCSI end-points, called - initiators and targets, each have a globally-unique name, defined in - [NDT]. - - An iSCSI name is a string of UTF-8 [RFC2044] characters that includes - a type designator, a naming authority based on domain names, and a - unique part within the naming authority. The unique part may be - generated based on anything the naming authority deems useful, and - may include user input. - - These names may need to be transcribed (sent between two - administrators via email, voice, paper, etc), so a case- insensitive - comparison would be desirable. However, these names must often be - compared by initiator and target implementations, most of which are - done in simple, embedded software. This makes case-sensitive - comparison highly desirable for these implementors. - - However, a completely case-sensitive implementation would result in - identifiers such as "example-name" and "Example-Name" being - different, which could lead to confusion as these names are - transcribed. - - The goal, then, is to generate iSCSI names that can be transcribed - and entered by users, and also compared byte-for-byte, with minimal - confusion. To attain these goals, iSCSI names are generalized using - a normalized character set (converted to lower case or equivalent), - with no white space allowed, and very limited punctuation. - - For those using only ASCII characters (U+0000 to U+007F), the - - - -Bakke Expires April 2003 [Page 2] - -Internet Draft String Profile for iSCSI Names October 2002 - - - following characters are allowed: - - - ASCII dash character ('-' = U+002d) - - ASCII dot character ('.' = U+002e) - - ASCII colon character (':' = U+003a) - - ASCII lower-case characters ('a'..'z' = U+0061..U+007a) - - ASCII digit characters ('0'..'9' = U+0030..U+0039) - - In addition, any upper-case characters input via a user interface - should be mapped to their lower-case equivalents. - - This document specifies the valid character set for iSCSI names, - along with the rules for normalizing and generating iSCSI names based - on user inport or other information that contains international - characters. - - In particular, it defines the following, as required by [STRINGPREP]: - - - The intended applicability of the profile: internationalized iSCSI - names. - - - The character repertoire that is the input and output to - stringprep: Unicode 3.1, specified in section 2. - - - The mappings used: specified in section 3. - - - The Unicode normalization used: specified in section 4. - - - The characters that are prohibited as output: specified in section - 5. - - This profile MUST be used with the iSCSI protocol. - - -2. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - Examples in this document use the notation for code points and names - from the Unicode Standard [Unicode3.1] and ISO/IEC 10646 [ISO10646]. - For example, the letter "a" may be represented as either "U+0061" or - "LATIN SMALL LETTER A". In the lists of prohibited characters, the - "U+" is left off to make the lists easier to read. The comments for - character ranges are shown in square brackets (such as "[SYMBOLS]") - and do not come from the standards. - - - - -Bakke Expires April 2003 [Page 3] - -Internet Draft String Profile for iSCSI Names October 2002 - - -3. Character Repertoire - - This profile uses Unicode 3.1, as defined in [STRINGPREP] Appendix - A.1. - - -4. Mapping - - This profile specifies mapping using the following tables from - [STRINGPREP]. The following mapping tables MUST be used when - generating iSCSI names from Unicode characters. - - Table B.1 - Table B.2 - - -5. Normalization - - Unicode normalization form KC MUST be used with this profile, as - described in [STRINGPREP]. - - -6. Prohibited Output - - This profile specifies prohibiting using the following tables from - [stringprep]. Characters appearing within these tables MUST NOT be - used within an iSCSI name. - - Table C.1 - Table C.2 - Table C.3 - Table C.4 - Table C.5 - Table C.6 - Table C.7 - Table C.8 - Table C.9 - - Important note: this profile MUST be used with the iSCSI protocol. - The iSCSI protocol has additional naming rules that are checked - outside of this profile. - - In addition, this profile adds the following prohibitions. The full - set of prohibited characters are those from the tables above plus - those listed individually below. - - - - - - -Bakke Expires April 2003 [Page 4] - -Internet Draft String Profile for iSCSI Names October 2002 - - -6.1. Inappropriate Characters from Common Input Mechanisms - - u+3002 is used as if it were u+002e in many domain name input - mechanisms used by applications, particularly in asia. The character - u+3002 MUST NOT be used in an iSCSI name. - - 3002; ideographic full stop - - -6.2. Currently-prohibited ASCII characters - - Some of the ASCII characters that are currently prohibited in iSCSI - names by [NDT] are also used in protocol elements such as URIs [URI]. - The other characters in the range U+0000 to U+007F that are not - currently allowed are prohibited in iSCSI names to reserve them for - future use in protocol elements. Note that the dash (U+002D), dot - (U+002E), and colon (U+003A) are not prohibited. - - The following characters MUST NOT be used in iSCSI names: - - 0000-002C; [ASCII CONTROL CHARACTERS and SPACE through ,] - 002F; [ASCII /] - 003B-0040; [ASCII ; through @] - 005B-0060; [ASCII [ through `] - 007B-007F; [ASCII { through DEL] - - -7. Unassigned Code Points in Internationalized Domain Names - - If the processing in [iSCSI] specifies that a list of unassigned code - points be used, the system uses table A.1 from [STRINGPREP] as its - list of unassigned code points. - - -8. Security Considerations - - ISO/IEC 10646 has many characters that look similar. In many cases, - users of security protocols might do visual matching, such as when - comparing the names of trusted third parties. This profile does - nothing to map similar-looking characters together. - - iSCSI names may be used by an initiator to verify that a target it - has discovered is the correct one, and by a target to verify that an - initiator is to be allowed access. If these names are interpreted - and compared differently by different iSCSI implementations, an - initiator could gain access to the wrong target, or could be denied - access to a legitimate target. - - - - -Bakke Expires April 2003 [Page 5] - -Internet Draft String Profile for iSCSI Names October 2002 - - -9. IANA Considerations - - This is a profile of stringprep. When it becomes an RFC, it should be - registered in the stringprep profile registry. - - -10. Summary - - This document describes a stringprep profile to be used with programs - generating names for iSCSI initiators and targets. - - -11. Normative References - - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997, RFC 2119. - -[STRINGPREP] - Paul Hoffman and Marc Blanchet, "Preparation of - Internationalized Strings ("stringprep")", draft-hoffman- - stringprep-03, May 2002. - -[ISCSI] J. Satran, et. al. "iSCSI", draft-ietf-ips-iscsi-12.txt, - June 2002. - - -12. Informative References - - -[NDT] K. Voruganti, et. al. "iSCSI Naming and Discovery - Requirements", draft-ietf-ips-iscsi-name-disc-05, May 2002. - -[NAMEPREP] Paul Hoffman and Marc Blanchet. Nameprep: A Stringprep - Profile for Internationalized Domain Names. draft-ietf-idn- - nameprep-10, May 2002. - -[SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. - -[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode and - ISO 10646", October 1996, RFC 2044. - -[Unicode3.1] - The Unicode Standard, Version 3.1.0: The Unicode Consortium. - The Unicode Standard, Version 3.0. Reading, MA, Addison- - Wesley Developers Press, 2000. ISBN 0-201-61633-5, as - amended by: Unicode Standard Annex #27: Unicode 3.1 - . - - - -Bakke Expires April 2003 [Page 6] - -Internet Draft String Profile for iSCSI Names October 2002 - - -[ISO10646] ISO/IEC 10646-1:2000. International Standard -- Information - technology -- Universal Multiple-Octet Coded Character Set - (UCS) -- Part 1: Architecture and Basic Multilingual Plane. - -[URI] For example: Roy Fielding et al., "Uniform Resource - Identifiers: Generic Syntax", August 1998, RFC 2396; Robert - Hinden et. al, "IPv6 Literal Addresses in URL's", December - 1999, RFC 2732. Note that there are many other RFCs that - define additional URI schemes. - -Author Contact Information - - Mark Bakke - Cisco Systems, Inc. - 6450 Wedgwood Road - Maple Grove, MN - USA 55311 - - Voice: +1 763-398-1000 - E-Mail: mbakke@cisco.com - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - - - -Bakke Expires April 2003 [Page 7] - -Internet Draft String Profile for iSCSI Names October 2002 - - - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bakke Expires April 2003 [Page 8] - \ No newline at end of file diff --git a/draft-ietf-krb-wg-utf8-profile-00.txt b/draft-ietf-krb-wg-utf8-profile-00.txt deleted file mode 100644 index 99580f6..0000000 --- a/draft-ietf-krb-wg-utf8-profile-00.txt +++ /dev/null @@ -1,399 +0,0 @@ -Internet Draft Jeffrey Altman -draft-ietf-krb-wg-utf8-profile-00.txt Columbia University -February 12, 2002 -Expires in six months - - Stringprep Profile for Kerberos UTF-8 Strings - -Status of this memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other groups -may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material -or to cite them other than as "work in progress." - -To view the list Internet-Draft Shadow Directories, see -http://www.ietf.org/shadow.html. - - -Abstract - -This document describes how to prepare UTF-8 strings -in order to increase the likelihood that name input and name comparison -work in ways that make sense for typical users throughout the world. This -is a profile of the stringprep protocol developed in the IDN working group. - -1. Introduction - -This document specifies processing rules that will allow users to enter -Kerberos Principal Names and input to cryptographic String to Key functions. -It is a profile of stringprep [STRINGPREP]. - -This profile defines the following, as required by [STRINGPREP] - -- The intended applicability of the profile: internationalized -host name parts - -- The character repertoire that is the input and output to stringprep: -defined in Section 2 - -- The list of unassigned code points for the repertoire: defined -in Appendix F. - -- The mappings used: defined in Section 3. - -- The Unicode normalization used: defined in Section 4 - -- The characters that are prohibited as output: Defined in section 5 - - -1.2 Terminology - -The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and -"MAY" in this document are to be interpreted as described in RFC 2119 -[RFC2119]. - -Examples in this document use the notation for code points and names -from the Unicode Standard [Unicode3.1] and ISO/IEC 10646 [ISO10646]. For -example, the letter "a" may be represented as either "U+0061" or "LATIN -SMALL LETTER A". In the lists of prohibited characters, the "U+" is left -off to make the lists easier to read. The comments for character ranges -are shown in square brackets (such as "[SYMBOLS]") and do not come from -the standards. - - -2. Character Repertoire - -Unicode 3.1 [Unicode3.1] is the repertoire used in this profile. -The reason Unicode 3.1 was chosen instead of a version of -ISO/IEC 10646 is that ISO/IEC 10646 is expected to be updated soon after -this document becomes an RFC. Unicode 3.1 has the exact repertoire that -is expected in the next version of ISO/IEC 10646, and is therefore used -here. - - -3. Mapping - -This profile specifies stringprep mapping using the mapping table -in Appendix D. That table includes all the steps described in this -section. - -Note that text in this section describe how Appendix D was formed. It is -there for people who want to understand more, but it should be ignored -by implementors. Implementations of this profile MUST map based on -Appendix D, not based on the descriptions in this section of how -Appendix D was created. - -3.1 Mapped out - -The following characters are simply deleted from the input (that is, -they are mapped to nothing) because their presence or absence should not -make two strings different. - -Some characters are only useful in line-based text, and are otherwise -invisible and ignored. - -00AD; SOFT HYPHEN -1806; MONGOLIAN TODO SOFT HYPHEN -200B; ZERO WIDTH SPACE -FEFF; ZERO WIDTH NO-BREAK SPACE - -Variation selectors and cursive connectors select different glyphs, but -do not bear semantics. - -180B; MONGOLIAN FREE VARIATION SELECTOR ONE -180C; MONGOLIAN FREE VARIATION SELECTOR TWO -180D; MONGOLIAN FREE VARIATION SELECTOR THREE -200C; ZERO WIDTH NON-JOINER -200D; ZERO WIDTH JOINER - -3.2 Space Character Conversions - -The following Unicode spaces are to be mapped to 0020; SPACE: - -00A0; NO-BREAK SPACE -2000; EN QUAD -2001; EM QUAD -2002; EN SPACE -2003; EM SPACE -2004; THREE-PER-EM SPACE -2005; FOUR-PER-EM SPACE -2006; SIX-PER-EM SPACE -2007; FIGURE SPACE -2008; PUNCTUATION SPACE -2009; THIN SPACE -200A; HAIR SPACE -202F; NARROW NO-BREAK SPACE -3000; IDEOGRAPHIC SPACE - -4. Normalization - -This profile specifies using Unicode normalization form KC, as described -in [UAX15]. - -NOTE: There was some discussion on the mailing list that would suggest -that Unicode NFKC does not properly handle the composition of -normalized Hangul strings. Following the lead of the IDN working -group, the Kerberos working group will not attempt to second-guess the -the authors of Unicode 3.1 Annex 15 (formerly Technical Report 15) -[UAX15], which specifies the normalization methods, or the Ideographic -Rappaorteur Group (IRG), which is the formal subgroup of ISO/IEC -JTC1/SC2/WG2 charged with approving all CJKV elements of the Unicode -standards. Such issues are outside the working group's charter and -its area of expertise. - - -5. Prohibited Output - -This profile specifies using the prohibition table in Appendix E. - -Note that the subsections below describe how Appendix E was formed. They -are there for people who want to understand more, but they should be -ignored by implementors. Implementations of this profile MUST map based -on Appendix E, not based on the descriptions in this section of how -Appendix E was created. - -The collected lists of prohibited code points can be found in Appendix E -of this document. The lists in Appendix E MUST be used by implementations -of this specification. If there are any discrepancies between the lists -in Appendix E and subsections below, the lists in Appendix E always takes -precedence. - -Some code points listed in one section would also appear in other -sections. Each code point is only listed once in the tables in Appendix -E. - - -5.1 Control characters - -Control characters (or characters with control function) cannot be seen -and can cause unpredictable results when displayed. - -0000-001F; [CONTROL CHARACTERS] -007F; DELETE -0080-009F; [CONTROL CHARACTERS] -070F; SYRIAC ABBREVIATION MARK -180E; MONGOLIAN VOWEL SEPARATOR -2028; LINE SEPARATOR -2029; PARAGRAPH SEPARATOR -206A-206F; [CONTROL CHARACTERS] -FFF9-FFFC; [CONTROL CHARACTERS] -1D173-1D17A; [MUSICAL CONTROL CHARACTERS] - -5.2 Private use and replacement characters - -Because private-use characters do not have defined meanings, they are -prohibited. The private-use characters are: - -E000-F8FF; [PRIVATE USE, PLANE 0] -F0000-FFFFD; [PRIVATE USE, PLANE 15] -100000-10FFFD; [PRIVATE USE, PLANE 16] - -The replacement character (U+FFFD) has no known semantic definition in a -name, and is often displayed by renderers to indicate "there would be -some character here, but it cannot be rendered". For example, on a -computer with no Asian fonts, a name with three ideographs might be -rendered with three replacement characters. - -FFFD; REPLACEMENT CHARACTER - -5.3 Non-character code points - -Non-character code points are code points that have been allocated in -ISO/IEC 10646 but are not characters. Because they are already assigned, -they are guaranteed not to later change into characters. - -FDD0-FDEF; [NONCHARACTER CODE POINTS] -FFFE-FFFF; [NONCHARACTER CODE POINTS] -1FFFE-1FFFF; [NONCHARACTER CODE POINTS] -2FFFE-2FFFF; [NONCHARACTER CODE POINTS] -3FFFE-3FFFF; [NONCHARACTER CODE POINTS] -4FFFE-4FFFF; [NONCHARACTER CODE POINTS] -5FFFE-5FFFF; [NONCHARACTER CODE POINTS] -6FFFE-6FFFF; [NONCHARACTER CODE POINTS] -7FFFE-7FFFF; [NONCHARACTER CODE POINTS] -8FFFE-8FFFF; [NONCHARACTER CODE POINTS] -9FFFE-9FFFF; [NONCHARACTER CODE POINTS] -AFFFE-AFFFF; [NONCHARACTER CODE POINTS] -BFFFE-BFFFF; [NONCHARACTER CODE POINTS] -CFFFE-CFFFF; [NONCHARACTER CODE POINTS] -DFFFE-DFFFF; [NONCHARACTER CODE POINTS] -EFFFE-EFFFF; [NONCHARACTER CODE POINTS] -FFFFE-FFFFF; [NONCHARACTER CODE POINTS] -10FFFE-10FFFF; [NONCHARACTER CODE POINTS] - -The non-character code points are listed the PropList.txt file from the -Unicode database. - -5.4 Surrogate codes - -The following code points are permanently reserved for use as surrogate -code values in the UTF-16 encoding, will never be assigned to -characters, and are therefore prohibited: - -D800-DFFF; [SURROGATE CODES] - -5.5 Inappropriate for plain text - -The following characters should not appear in regular text. - -FFF9; INTERLINEAR ANNOTATION ANCHOR -FFFA; INTERLINEAR ANNOTATION SEPARATOR -FFFB; INTERLINEAR ANNOTATION TERMINATOR -FFFC; OBJECT REPLACEMENT CHARACTER - -5.6 Inappropriate for canonical representation - -The ideographic description characters allow different sequences of -characters to be rendered the same way, which makes them inappropriate -for host names that must have a single canonical representation. - -2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS] - -5.7 Change display properties - -The following characters, some of which are deprecated in ISO/IEC 10646, -can cause changes in display or the order in which characters appear -when rendered. - -200E; LEFT-TO-RIGHT MARK -200F; RIGHT-TO-LEFT MARK -202A; LEFT-TO-RIGHT EMBEDDING -202B; RIGHT-TO-LEFT EMBEDDING -202C; POP DIRECTIONAL FORMATTING -202D; LEFT-TO-RIGHT OVERRIDE -202E; RIGHT-TO-LEFT OVERRIDE -206A; INHIBIT SYMMETRIC SWAPPING -206B; ACTIVATE SYMMETRIC SWAPPING -206C; INHIBIT ARABIC FORM SHAPING -206D; ACTIVATE ARABIC FORM SHAPING -206E; NATIONAL DIGIT SHAPES -206F; NOMINAL DIGIT SHAPES - -5.8 Tagging characters - -The following characters are used for tagging text and are invisible. - -E0001; LANGUAGE TAG -E0020-E007F; [TAGGING CHARACTERS] - - -6. Unassigned Code Points in Internationalized Host Names - -This profile lists the unassigned code points for Unicode 3.1 in -Appendix F. The list in Appendix F MUST be used by implementations of -this specification. If there are any discrepancies between the list in -Appendix F and the Unicode 3.1 specification, the list Appendix F always -takes precedence. - - -7. Security Considerations - -ISO/IEC 10646 has many characters that look similar. In many cases, -users of security protocols might do visual matching, such as when -comparing the names of trusted third parties. This profile does nothing -to map similar-looking characters together. - -Principal names and passwords are entered by users and used within the -Kerberos protocol. The -security of the Internet would be compromised if a user entering a -single internationalized string could be connected to different servers -or denied access based on different interpretations of -internationalized strings. - -8. References - -[CharModel] Unicode Technical Report;17, Character Encoding Model. -. - -[Glossary] Unicode Glossary, . - -[ISO10646] ISO/IEC 10646-1:2000. International Standard -- Information -technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part -1: Architecture and Basic Multilingual Plane. - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", March 1997, RFC 2119. - -[STRINGPREP] Paul Hoffman and Marc Blanchet, "Preparation of -Internationalized Strings ("stringprep")", draft-hoffman-stringprep, -work in progress - -[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode -Consortium. The Unicode Standard, Version 3.0. Reading, MA, -Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended -by: Unicode Standard Annex #27: Unicode 3.1 -. - -[UAX15] Mark Davis and Martin Duerst. Unicode Standard Annex #15: -Unicode Normalization Forms, Version 3.1.0. - - - -A. Acknowledgements - -This draft is based upon the work of the IETF IDN Working Group's -IDN Nameprep design team. - -B. IANA Considerations - -This is a profile of stringprep. When it becomes an RFC, it -should be registered in the stringprep profile registry. - -C. Author Contact Information - -Jeffrey Altman -jaltman@columbia.edu -Columbia University -612 West 115th Street -New York NY 10025 - - -D. Mapping Tables - -The following is the mapping table from Section 3. The table has three -columns: -- the character that is mapped from -- the zero or more characters that it is mapped to -- the reason for the mapping -The columns are separated by semicolons. Note that the second column may -be empty, or it may have one character, or it may have more than one -character, with each character separated by a space. - ------ Start Mapping Table ----- -... to be filled in ... ------ End Mapping Table ----- - - -E. Prohibited Code Point List - ------ Start Prohibited Table ----- -... to be filled in ... ------ End Prohibited Table ----- - -NOTE WELL: Software that follows this specification that will be used to -check names before they are put in authoritative name servers MUST add -all unassigned code pints to the list of characters that are prohibited. -See Section 6 of [STRINGPREP] for more details. - - -F. Unassigned Code Point List - ------ Start Unassigned Table ----- -... to be filled in ... ------ End Unassigned Table ----- - - - - - Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! - The Kermit Project @ Columbia University includes Telnet, FTP and HTTP - http://www.kermit-project.org/ secured with Kerberos, SRP, and - kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH -- 2.11.4.GIT