Changes between Version 4 and Version 5 of TypicalAppsAreaIssues


Ignore:
Timestamp:
Jun 6, 2013, 2:41:02 AM (6 years ago)
Author:
barryleiba@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TypicalAppsAreaIssues

    v4 v5  
    2929=== Character Sets ===
    3030
    31 Your spec might have various textual protocol elements, but not explicitly mention the allowable charsets. In IETF protocols, UTF-8 is preferred (along with US-ASCII, which is a subset of UTF-8). See RFC 2277 (BCP 18), Sections 3.1 and 3.2.
     31Your spec might have various textual protocol elements, but not explicitly mention the allowable charsets. In IETF protocols, UTF-8 is preferred (along with US-ASCII, which is a subset of UTF-8). See RFC 2277 (BCP 18), Sections 3.1 and 3.2.  And see below about Unicode Normalization.
    3232
    33 === HTTP ===
     33=== Unicode Normalization ===
    3434
    35 ==== New Header Fields ====
    36 
    37 http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-3.1 has advice on how to define new header fields (syntax, interaction with other parts of HTTP like caching, ...)
    38 
     35If your spec has protocol elements for usernames, passwords, or identifiers of any kind, please specify how Unicode characters in such fields will be normalized. Visit http://unicode.org/ for details.  See (and possibly cite) RFC 5198 for informattion about UTF-8 and normalization.  If your character strings might be entered by users and/or might be compared for equality, you will need to consider normalization and canonicalization issues.
    3936
    4037=== Internationalized Domain Names ===
     
    4845One common approach is to carry the language tag in a separate field (e.g., in XML the "xml:lang" attribute, in ASN.1 by a new field). Such a field can be attached to each element requiring the language tag, or can be global for the whole object/document.
    4946
    50 === Passwords ===
     47== HTTP ==
    5148
    52 Binary passwords should have a standard way to represent them to users/enter in configuration files (e.g., hex).
     49=== New Header Fields ===
    5350
    54 === Unicode Normalization ===
     51http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-3.1 has advice on how to define new header fields (syntax, interaction with other parts of HTTP like caching, ...)
    5552
    56 If your spec has protocol elements for usernames, passwords, or identifiers of any kind, please specify how Unicode characters in such fields will be normalized. Visit http://unicode.org/ for details.
     53== Passwords ==
     54
     55Binary passwords should have a standard way to represent them to users/enter in configuration files (e.g., hex).  Text passwords will almost certainly have internationalization issues; see above.
    5756
    5857== Media Types ==
     
    6261If your spec has a protocol element that is defined to contain a media type, make sure you specify if MIME-related parameters are allowed (e.g. 'text/plain' versus 'text/plain;charset=UTF-8').
    6362
    64 If your spec defines a new media type registration, you need to follow the process defined in Section 5 of RFC 4288 (also read RFC 2046 for background information). In essence, that means you need to do the following:
     63If your spec defines a new media type registration, you need to follow the process defined in RFC 6838 (also read RFC 2046 for background information). In essence, that means you need to do the following:
    6564
    66   * Using the template in RFC 4288, create a registration and add it to your spec (review some of the similar registrations at http://www.iana.org/assignments/media-types/application/ for insights).
     65  * Using the template in RFC 6838, create a registration and add it to your spec (review some of the similar registrations at http://www.iana.org/assignments/media-types/application/ for insights).
    6766
    68   * Submit your actual registration (not a pointer to it) for review by the Expert Reviewers on the ietf-types@iana.org discussion list.
     67  * Submit your actual registration (not a pointer to it) for review on the ietf-types@iana.org discussion list.  Do this '''before''' you're ready to request publication of your draft.
    6968
    70   * Wait two weeks for review comments and make sure you respond to the feedback provided on the list.
     69  * Wait at least two weeks for review comments and make sure you respond to the feedback provided on the list.
    7170
    7271== Security ==
     
    113112
    114113An [http://www.w3.org/2001/03/webdata/xsv online schema validator] is available at the W3C.
    115