[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New Version Notification for draft-seantek-text-nfo-02.txt
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: internet-drafts@ietf.org
> 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 <dev+ietf@seantek.com>
Restrictions on usage: None.
Author/Change controller: Sean Leonard <dev+ietf@seantek.com>
Intended usage: COMMON
Provisional registration? No
*****
To: ietf-charsets@iana.org
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 <dev+ietf@seantek.com>
Intended usage: COMMON
*END*
smime.p7s