Re: [pkix] [rfc-i] v3imp #3 Verbatim text

Sean Leonard <dev+ietf@seantek.com> Sat, 31 January 2015 19:22 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB09E1A1AFB for <pkix@ietfa.amsl.com>; Sat, 31 Jan 2015 11:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUQzFGapktJ6 for <pkix@ietfa.amsl.com>; Sat, 31 Jan 2015 11:22:29 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0301A1B0E for <pkix@ietf.org>; Sat, 31 Jan 2015 11:22:26 -0800 (PST)
Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EF56A22E25F; Sat, 31 Jan 2015 14:22:19 -0500 (EST)
Message-ID: <54CD2B67.9000600@seantek.com>
Date: Sat, 31 Jan 2015 11:22:15 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: rfc-interest@rfc-editor.org
References: <54C20E4D.9010301@seantek.com>
In-Reply-To: <54C20E4D.9010301@seantek.com>
Content-Type: multipart/mixed; boundary="------------000404000503060802070900"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/qwZBDusu9sEZ6KZ1SDeF5QWq2VQ>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] [rfc-i] v3imp #3 Verbatim text
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Jan 2015 19:22:31 -0000

On 1/23/2015 1:03 AM, Sean Leonard wrote:
> Improvement Need
> #3 Verbatim text

I would like to narrow this Improvement down to very modest and focused 
proposals for phrasing content (specification text), below.

The samples in the attachments are taken from PKIX-related documents 
draft-josefsson-pkix-textual-10 and RFC 5280, and further discussed below.


    Elements

• named items: <named> (or <keyword> — extend the current element in the 
model). A named item is a keyword or key phrase of semantic significance 
in the specification, and is expected to occur in normative block-level 
text such as text found in <sourcecode>, <artwork>, and (if accepted) 
<attachment> elements. Examples of named items include variables, 
computer language keywords, field names, and ABNF rule names. Tools can 
generate automatic links or cross-references between <named> elements 
and the texts where the named elements occur. When rendered, named items 
may use the same typeface as <artwork> and <sourcecode> elements. A 
named item is a sequence of Unicode code points.
HTML5 ≈ <var> <code>

• literals: <lit> (or <verb> for verbatim). A literal serves as 
exemplary data in the specification. Examples of literals include sample 
output, sample input, magic numbers, labels, and specific identifiers or 
values (e.g., TRUE, 777). When rendered, literals should appear visually 
distinct from non-literal content, and should use the same typeface as 
<tt>, <artwork>, and <sourcecode> elements. A literal is a sequence of 
Unicode code points. Tools can provide affordances and functions to 
display and extract the exact code points. Apparently replaces <spanx 
style="verb"> and <spanx style="vbare">, with the semantics.
HTML5 ≈ <samp> <kbd> ~<q>

◦ teletype: <tt> (already in v3 draft—therefore no change required). 
Monospace style only. Apparently replaces <spanx style="verb"> and 
<spanx style="vbare">, without any semantics. Compare with <lit> above.
HTML5 ≈ ‼ apparently <tt> was removed from HTML5...


    Notes and Quotes

<q> was considered (as the phrasing content equivalent to <blockquote>), 
both for literals and for prose quotations from other documents, but was 
rejected: quotation marks are working out just fine. The spec-text is 
US-English so we can stick with regular English punctuation marks.

We may wish to have an editorial policy that changes "" to “” and ‘’. 
The left and right quotation marks are much clearer than the US-ASCII 
generic (and overloaded) " and ' marks. When delimiting or quoting 
US-ASCII content, “” is extremely clear since “ and ” characters are not 
US-ASCII. For example, quoting the quotation mark sometimes looks like 
""" — “"” is much clearer. Other standards organizations such as ISO use 
left and right quotation marks in their standards.


    Samples

The attached samples are extracts from the canonical plain text versions 
of draft-josefsson-pkix-textual-10 and RFC 5280. I have marked up the 
plain text with the following PDF annotations:
Cyan-blue highlight
	named items/keywords
Green highlight
	literals
_Red underline_
	teletype (monospace) text


These samples should make the broad utility of this proposal clear.

Sean