Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)

[Ángel <[e-mail]>]

On 2021-02-26 at 23:00 -0500, Daniel Kahn Gillmor wrote:
> Thanks for this close read, Ángel.
> 
> You raised so many points in one message that i'm afraid some of them
> might get lost.
> 
> I'm trying to address all of your concerns, either with a merge request
> (MR) with a simple editorial patch, a call for further discussion, or a
> new issue in gitlab.
> 
> If you want to follow up on one or the other, i recommend referring
> to the specific issue or merge request in the subject of the mailing
> list thread, if one exists.
> 
> I encourage folks to do this kind of tracking/triage on the issues
> they raise on-list directly, it's quite a bit of work to make sure
> that all the points get tracked so they can be handled.

Thanks for that. Feel free to ask for patches. It seemed odd to simply
propose a MR without first presenting that to the wg. What I consider a
good phrasing may not be considered so by someone else. Or just come up
with a better one.
Not sure how to proceeds without flooding with mails or issues/MR or
everything. It's straightforward if everyone simply agrees, but for
things that get discussed, it would be easy to lose track of that, yes.


I'm replying here directly to some points, stripping unrelated pieces,
and splitting another two blocks as different threads.

Best regards


> On Fri 2021-02-26 02:25:49 +0100, Ángel wrote:
> 
> > I would prefer to keep single quotes for values referring to single
> > bytes standing by themselves, as rfc4880 did. -00 changed them to
> > double quotes but using single quotes as in C seems better.
> > 
> > This happens in
> > * 5.9.  Literal Data Packet (Tag 11)
> > ('b', 't', 'u', 'l', '1') vs ("b", "t", "u", "l", "1")
> > 
> > * 6.2.  Forming ASCII Armor with '-' and ':'
> > * 7.1.  Dash-Escaped Text with '-'
> > 
> > but does *not* apply to the characters in 8. Regular Expressions
> 
> I'm not sure how to address this request without doing some heavy
> lifting in the toolchain, espcially since it looks like you want the
> tooling to behave differently for characters in the two different
> places.
> 
> Please take a look at the HTML rendering
> (
> https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-02.html
> )
> which sets off these literal string representations in a clearly
> different style.  I think that's an improvement worth keeping.
> 
> I'm also not sure how much single vs double quotes matters here.  If
> you want to propose a fix we can discuss it though :)

Wow. That's even worse. I can't really see a difference here (they may
have a slightly different font, I'm not even sure about that, that'd be
barely noticeable). I guess that's completely different at your side.
I'm attaching a screenshot.
I see they get into <code> tags, so it could be just a matter of adding
CSS.


> > Additionally, in 7.1 a single-quoted space (' ') was
> > converted to use backticks (` `), which seems like an
> > error when converting the document. It makes sense
> > in some markdown conversions, but not in the rfc results.
> 
> hm, yes, this looks like a bug in kramdown-rfc2629 which i've
> reported
> here:
> 
>   https://github.com/cabo/kramdown-rfc2629/issues/108
> 
> I've proposed a formatting workaround:
> 
>    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/34
> 
> -Dash-escaped cleartext is the ordinary cleartext where every line
> starting with a dash `-` (0x2D) is prefixed by the sequence dash `-`
> (0x2D) and space ` ` (0x20).
> +Dash-escaped cleartext is the ordinary cleartext where every line
> starting with a <u>-</u> is prefixed by the sequence <u>-</u> and <u>
> </u>.
> 
> This results in  the following change in the .txt version:
> 
> […]
>     Dash-escaped cleartext is the ordinary cleartext where every line
> -   starting with a dash "-" (0x2D) is prefixed by the sequence dash
> "-"
> -   (0x2D) and space ` ` (0x20).  
> +   starting with a "-" (HYPHEN-MINUS, U+002D) is prefixed by the
> +   sequence "-" (HYPHEN-MINUS, U+002D) and " " (SPACE, U+0020).
> […]
> 
> Hopefully that is no less clear than before, and the rendering is
> more normalized without the backticks.

Are those underlines? It seems (semantically) strange. The solution of
Paul of simply putting literal ' seems better, although maybe there's a
way to get a better output for html. I should have a look at the source
and what kramdown-rfc is doing.



> > In appendix A, an extra space was inserted between "Philip R." 
> > and "Zimmermann" (Appendix C in -02)
> 
> I initially thought this was an artifact of the ./reflow
> script.  I've
> added a special case to avoid it while still being able to use
> ./reflow,
> and suggested the fix here:
> 
>    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/35
> 
> However, it looks like this is actually a bug in xml2rfc, which wants
> to
> put two spaces between a period and the next sentence.
> 
> I've reported this here:
> 
>    
> https://mailarchive.ietf.org/arch/msg/xml2rfc/6V7C7l-zxg97jRqvuaq8r1QBQqw/

I have no problem with the nbsp, although manually looking for "Philip
R. Zimmerman" in reflow looks like a hack (although if someone deserves
to appear there it's him).
Instead of adding that for, I would change the preceding split not to
split for single letters:
>     # assume all sentences split with a period (.), and not ! or ?
>     # also, accept accidental breaks on abbreviations like John Q.
> Public
> -    sentences:List[str] = x.split('. ')
> +    sentences:List[str] = re.split("(?<! [A-Z])\. ", x)

Although with the nbsp, '. ' shouldn't match, anyway.



It's funny how many of these things turned out to be toolchain issues.
I'm not sure I would have been able to track them as you did.



> > crypto-refresh-01/02 nitpicks
> > =====
> > At 1. Introduction, change "RFC 5581 (Camellia cipher)" to "RFC 5581
> > (The Camellia Cipher in OpenPGP)" or "RFC 5581 (Camellia Cipher in
> > OpenPGP)", since just "Camellia cipher" could be confused with the
> > description itself of Camellia (rfc3713).
> > "ECC for OpenPGP" should perhaps be changed to "ECC in OpenPGP" which is the
> > preposition used in that rfc title.
> > Full name of RFC 6637 is "Elliptic Curve Cryptography (ECC) in OpenPGP" and
> > would be the proper one if we wanted to use the complete names of the rfc,
> > albeit I don't think that would matter either way.
> 
> These aren't the full RFC names 

> (4880 itself is not "OpenPGP"),

I noticed :-)

> they're shorthand labels, but i agree that they should be normalized
> to be more readable.  I submitted the editorial suggestion
> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/36 to make
> them "Camellia in OpenPGP" and "Elliptic Curves in OpenPGP".

Good.




Best,
Ángel