idnits 2.17.1 draft-hoffman-char-lang-media-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 198 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of lines with control characters in the document. ** The abstract seems to contain references ([TAG-REG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2000) is 8697 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2278 (ref. 'CHARSET') (Obsoleted by RFC 2978) ** Obsolete normative reference: RFC 1766 (ref. 'LANG') (Obsoleted by RFC 3066, RFC 3282) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman 2 draft-hoffman-char-lang-media-04.txt Internet Mail Consortium 3 July 3, 2000 4 Expires in six months 6 Registration of Charset and Languages Media Features Tags 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document contains the registration for two media feature tags: 31 "charset" and "language". These media features allow specification of 32 character sets and human languages that can be understood by devices 33 and the devices' users. The templates in this document are derived from 34 [TAG-REG]. 36 1. Registration for charset 38 To: media-feature-tags@apps.ietf.org (Media feature tags mailing list) 39 Subject: Registration of media feature tag charset 41 Media feature tag name: 42 charset 44 ASN.1 identifier associated with feature tag: 45 New assignment by IANA 47 Summary of the media feature indicated by this feature tag: 48 Ability to display particular charsets as defined in [CHARSET]. For 49 most devices, this media feature is usually a capability; that is, 50 most devices cannot intelligently process text in a charset that 51 is unknown to the device. 53 Values appropriate for use with this feature tag: 54 The values are tokens as defined in [CHARSET]. The values can only 55 be compared for equality. Comparison is not case sensitive. 57 The feature tag is intended primarily for use in the following 58 applications, protocols, services, or negotiation mechanisms: 59 Any protocol that uses media tags 61 Examples of typical use: 62 (| (charset=utf-8);q=1.0 (charset=iso-8859-1);q=0.9 63 (charset=utf-16);q=0.5 ) 65 Related standards or documents: 66 "IANA Charset Registration Procedures", RFC 2278 68 Considerations particular to use in individual applications, 69 protocols, services, or negotiation mechanisms: 70 None 72 Interoperability considerations: Aliases for charsets should not be 73 used in media feature expressions because feature expression 74 manipulation tools may convert aliases to the the principal name 75 for the charset. Even though charset names are not case-sensitive, 76 values should be expressed as all lowercase letters to increase the 77 likelihood of interoperability. The "charset" capability should 78 always be indicated in conjunction with any capability to handle 79 textual data. 81 Security considerations: 82 If it is known that there is a security bug in the display 83 of a particular charset in a particular environment, knowing 84 that a device can accept that charset may slightly help an 85 attacker. 87 Additional information: 88 None 90 Name(s) & email address(es) of person(s) to contact for 91 further information: 92 Paul Hoffman 94 Intended usage: 95 COMMON 97 Author/Change controller: 98 IETF 100 Requested IANA publication delay: 101 None 103 Other information: 104 None 106 2. Registration for language 108 To: media-feature-tags@apps.ietf.org (Media feature tags mailing list) 109 Subject: Registration of media feature tag language 111 Media feature tag name: 112 language 114 ASN.1 identifier associated with feature tag: 115 New assignment by IANA 117 Summary of the media feature indicated by this feature tag: 118 Ability to display particular human languages as defined in [LANG]. 119 Note that "display" in this case will most often mean speech 120 by a computer. For most devices, this media feature is a preference, 121 not a requirement. 123 Values appropriate for use with this feature tag: 124 The values are tokens, with allowable values defined by 125 registration as defined in [LANG]. The values can only be compared 126 for equality. As described in [LANG], language tags are always 127 handled as a single token, and "subtags" are not used for 128 comparison. Comparison is not case sensitive. 130 The feature tag is intended primarily for use in the following 131 applications, protocols, services, or negotiation mechanisms: 132 Any protocol that uses media tags 134 Examples of typical use: 135 (| (language=no-nynorsk);q=1.0 (language=no-bokmaal);q=0.9 136 (language=i-sami-no);q=0.5 ) 138 Related standards or documents: 139 "Tags for the Identification of Languages", RFC 1766 141 Considerations particular to use in individual applications, 142 protocols, services, or negotiation mechanisms: 143 None 145 Interoperability considerations: 146 Even though langage tags are not case-sensitive, values should be 147 expressed as all lowercase letters to increase the likelihood of 148 interoperability. 150 Security considerations: 151 If it is known that there is a security bug in the display 152 of a particular language in a particular environment, knowing 153 that a device can accept that language may slightly help an 154 attacker. 156 Additional information: 157 None 159 Name(s) & email address(es) of person(s) to contact for 160 further information: 161 Paul Hoffman 163 Intended usage: 164 COMMON 166 Author/Change controller: 167 IETF 169 Requested IANA publication delay: 170 None 172 Other information: 173 None 175 3. Security Considerations 177 The security considerations are listed in the two registrations above. 179 4. IANA Considerations 181 The bulk of this document is IANA registrations. 183 5. References 185 [CHARSET] "IANA Charset Registration Procedures", RFC 2278 187 [LANG] "Tags for the Identification of Languages", RFC 1766 189 [TAG-REG] "Media Feature Tag Registration Procedure", RFC 2506 191 6. Author Contact Information 193 Paul Hoffman 194 Internet Mail Consortium 195 127 Segre Place 196 Santa Cruz, CA 95060 USA 197 phoffman@imc.org