Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <200504050532.BAA14093%Sparkle.Rodents.Montreal.QC.CA@localhost> you write:
>If you want to provide a spec for encoding public keys as octet streams
>containing sequences of lines delimited by line termination sequences,
>that's fine, but that's (a) less useful (because it requires converting
>between octet-stream representations and native representations for
>filesystems that don't use line termination sequences) and (b) not what
>publickeyfile-08 calls itself.

Um, section 2 makes it fairly clear that the format described is for
exchanging public keys between implementations, rather than necessarily for
use within an implementation.  It could probably be clearer.

>3.3
>   The Header-tag MUST NOT be more than 64 bytes, and is
>   case-insensitive.  The Header-value MUST NOT be more than 1024 bytes.
>   Each line in the header MUST NOT be more than 72 bytes.
>
>Since the Header-tag is explicitly declared case-insensitive, I'd
>prefer to see the case-sensitivity of the Header-value mentioned, even
>if only with wording like "...more than 1024 bytes, and, depending on
>the Header-tag, may or may not be case-sensitive.".

I don't think case-sensitivity is a useful concept to apply to header-values
in the abstract.  To take an analogy, would you say that the RFC-822
"Subject" header is case-sensitive or not?

>3.3
>   A line that is not a continuation line that has no ':' in it is the
>   first line of the base 64 encoded body (See Section 3.4.)
>
>s/base 64/base-64/ here?

"base64-encoded", actually.  See RFC 2045.

-- 
Ben Harris