Subject: [apps-discuss] New Version Notification for draft-seantek-text-nfo-02.txt

From: Sean Leonard <[email-masked]>
Date: Sun, 4 Oct 2015 17:37:36 -0700

A new version of the Independent Submission for the media type text/nfo is posted; comments welcome.

Per IETF policies, the media type registration template is provided below for the sake of media-types@ ; the charset registration template is provided below for the sake of ietf-charsets@ .

(Note that the last time that I submitted the template to ietf-charsets@ on September 5, 2015, I got a bounce back. Not good.)

Sean

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-seantek-text-nfo-02.txt
> Date: October 4, 2015 at 5:29:52 PM PDT
> 

A new version of I-D, draft-seantek-text-nfo-02.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-text-nfo
Revision:	02
Title:		The text/nfo Media Type
Document date:	2015-10-04
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-seantek-text-nfo-02.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-text-nfo/
Htmlized:       https://tools.ietf.org/html/draft-seantek-text-nfo-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-text-nfo-02

Abstract:
  This document registers the text/nfo media type for use with release
  iNFOrmation. While mostly compatible with text/plain, ".NFO" files
  and content have unique encoding and rendering characteristics that
  make them distinguishable from typical plain text.

*****
2. Release iNFOrmation Media Type Registration Application

   Type name: text

   Subtype name: nfo

   Required parameters:

    charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. Unlike
     most other text types, the default value is the character set of
     the original IBM PC and MS-DOS, called OEM Code Page 437, and named
     "oem437". Implementations MUST support OEM Code Page 437.
     Unfortunately, the simple application of the IANA registered
     character set "IBM437" (aka "cp437") [RFC1345] will miss some
     important characters, so conformant implementations MUST support
     OEM Code Page 437 as specified in Section 3. NFOs authored for more
     modern computing environments are known to use ISO-8859-1, ISO-
     8859-15 (including support for the Euro sign), or UTF-8; however,
     for maximum interoperability, these or any other character sets
     MUST be declared by the sender. When absent, a receiver MAY guess,
     but SHOULD heavily bias the outcome towards OEM Code Page 437
     unless UTF-8 encoding is patently obvious. A RECOMMENDED detection
     algorithm is provided in Appendix A.

   Optional parameters:

    baud: A natural number (integer greater than 0) indicating the gross
     bit rate at which the NFO is supposed to be rendered to screen.
     This optional parameter provides a nostalgic effect from the days
     of modems and fixed-speed serial lines. It also controls the
     animation rate, to the extent that the NFO employs optional escape
     sequences.

   Encoding considerations:

     Text with 8-bit code points; all 8-bit combinations (including NUL)
     are possible. Accordingly, text SHOULD be quoted-printable or
     base64 encoded when transmitted over a channel that is not 8-bit
     clean.

   Security considerations: 

     It's just text; this format provides no facilities for
     confidentiality or integrity. The ANSI escape sequence "CSI 5 m"
     could, however, blink you to death. As only a subset of ANSI escape
     sequences MUST be interpreted; interpreting a greater range than
     the subset prescribed in this registration may introduce other
     security issues, such as transmitting operating system commands.

     Some code points in oem437 have been used ambiguously in practice,
     so implementations SHOULD NOT assume that the mapping between this
     charset and Unicode is bijective. When displayed, codes 00, 20, and
     FF MAY appear to be similar, i.e., as a blank space.

   Interoperability considerations:

     NFOs are plain text but look best when read in a terminal view or
     with a dedicated NFO viewer that can emulate terminal features. As
     a result, they SHOULD be treated differently than text/plain files.
     The reference implementation that all NFO viewers SHOULD target is
     an IBM PC-compatible machine running MS-DOS 6.22 with the ANSI.SYS
     MS-DOS device driver loaded, where the NFO is displayed as if it
     were output to the terminal using the "TYPE" command.

   Published specification: [[Note to RFC Editor: Insert number here.]]

   Applications that use this media type:

     NFO viewers; text editors; terminals.

   Fragment identifier considerations:

     Same as text/plain [RFC5147]. Note that escape sequences do not
     contribute to the character count [[NB: do they?]], and line breaks
     are treated as one character, regardless of whether CRLF or some
     other code(s) are used.

   Additional information:

     Deprecated alias names for this type: text/x-nfo
     File extension(s): .nfo
     Macintosh file type code(s):
       TEXT. A uniform type identifier (UTI) of "public.nfo", which
       conforms to "public.plain-text", is RECOMMENDED.

   Person & email address to contact for further information:

     Sean Leonard <[email-masked]>

   Restrictions on usage: None.

   Author/Change controller: Sean Leonard <[email-masked]>

   Intended usage: COMMON

   Provisional registration? No

*****
     To: [email-masked]
     Subject: Registration of new charset oem437

     Charset name: oem437

     Charset aliases: None.

     Suitability for use in MIME text: Suitable.

     Published specification(s): This specification; [OEMCP437].

     ISO 10646 equivalency table:

       This table is taken from the IBM437 registration in [RFC1345],
       with modifications based on actual implementations of [OEMCP437],
       as discussed in this document. Character mnemonic symbols
       generally map to the Unicode code points listed in Section 3
       of [RFC1345], with the following exceptions. The symbol suffix
       $ (for example, HT$) means that the Unicode code point
       mapping is essentially correct, but an implementation might
       need to perform additional or special processing as discussed
       in this document, depending on the output environment.
       The symbol $$ means that this code point has special
       considerations as discussed in this document, so no
       single, definitive Unicode code point mapping can be given.
       Finally, three characters have no corresponding mnemonic
       symbols in Section 3 of [RFC1345], so symbols are defined here:

         $>   25ba   BLACK RIGHT-POINTING POINTER
         $<   25c4   BLACK LEFT-POINTING POINTER
         $B   21a8   UP DOWN ARROW WITH BASE

       NU$ 0u 0U cH- cD- cC cS BL$ BS$ HT$ LF$ Ml Fm CR$ M2 SU
       $> $< UD !*2 PI SE SR $B -! -v $$ EC$ -L <> UT Dt
       SP !  "  Nb DO %  &  '  (  )  *  +  ,  -  .  /
       0  1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?
       At A  B  C  D  E  F  G  H  I  J  K  L  M  N  O
       P  Q  R  S  T  U  V  W  X  Y  Z  <( // )> '> _
       '! a  b  c  d  e  f  g  h  i  j  k  l  m  n  o
       p  q  r  s  t  u  v  w  x  y  z  (! !! !) '? Eh
       C, u: e' a> a: a! aa c, e> e: e! i: i> i! A: AA
       E' ae AE o> o: o! u> u! y: O: U: Ct Pd Ye Pt Fl
       a' i' o' u' n? N? -a -o ?I NI NO 12 14 !I << >>
       .S :S ?S vv vl vL Vl Dl dL VL VV LD UL Ul uL dl
       ur uh dh vr hh vh vR Vr UR DR UH DH VR HH VH uH
       Uh dH Dh Ur uR dR Dr Vh vH ul dr FB LB lB RB TB
       a* $$ G* $$ $$ s* $$ t* F* H* $$ $$ 00 $$ $$ (U
       =3 +- >= =< Iu Il -: ?2 Ob .M Sb RT nS 2S fS NS$

     Additional information:

       See this document for details on how to handle particular codes
       that correspond both to graphemes in the IBM PC ROM, and
       to control characters.

     Person & email address to contact for further information:

       Sean Leonard <[email-masked]>

     Intended usage: COMMON

*END*