The Base45 Data Encoding
draft-faltstrom-base45-12

Thank you to Kyle Rose for the SECDIR review.

Thank you for the work on this document.

Many thanks to Harald Alvestrand for his ART ART review https://mailarchive.ietf.org/arch/msg/art/S-mc9GCVZ7Lxr1ydDaLGDawB4Tg/.

Only one additional editorial nit from me: 

   For example, it MUST the encoded data if it contains characters
   outside the base alphabet (in Table 1) when interpreting base-encoded
   data.

FP: missing the word "reject".

Francesca

# GEN AD review of draft-faltstrom-base45-10

CC @larseggert

Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/4EYF7jHNjPWxWmNDPA-18gdzJoo).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 7, paragraph 1
```
-    implementions are stable.
+    implementations are stable.
+            ++
```

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Grammar/style

#### "Table of Contents", paragraph 1
```
F-8 or ISO/IEC 8859-1 encoded text. Thus QR-codes cannot be used to encode ar
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

#### Section 4.1, paragraph 0
```
the data is to be sent via email. Instead the Base45 encoding should be remo
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Instead".

#### Section 4.2, paragraph 3
```
706 equals 11 + 45 * 11 + 45 * 45 * 8 so the sequence in base 45 is [11 11 8
                                     ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 6, paragraph 5
```
nd Gaby Whitehead for the feedback. Also everyone that have been working with
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Also".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Hi,

Thanks for this document.  No real objections, just some suggestions/nits that may improve this document for folks not familiar with QR codes.

(1) It wasn't really clear to me why Base-45 was useful, and why Base-64 wouldn't work.  I had missed the comment at the beginning of section 4 and it was only when I looked up the character sets for QR codes that it made sense.  I would suggest adding a sentence in the introduction to highlight/repeat this important bit of context.

(2) The section on "When to use Base45" doesn't really ever seem to say when to use it, and seems to only list when not to use it.  Perhaps this section is missing some text, or maybe the title should be changed to the reverse sense.

(3) In the Security Considerations, this sentence doesn't scan: 
  "it MUST the encoded data if it contains characters
   outside the base alphabet (in Table 1) when interpreting base-encoded
   data."

(4) In the Security Considerations:

   Even though a Base45 encoded string contains only characters from the
   alphabet in Table 1 the following case has to be considered: The
   string "FGW" represents 65535 (FFFF in base 16), which is a valid
   encoding.  The string "GGW" would represent 65536 (10000 in base 16),
   which is represented by more than 16 bit.

bit -> to bits.  This paragraph doesn't really sit well on its own and I would suggest merging the following paragraph into a single paragraph.

(5) Finally, it wasn't clear to me how a QR reader would know that it is reading/parsing some Base-45 encoded text from a QR code.  Is there a separate specification that indicates this?

Thanks,
Rob

Thanks for this specification. I think it will be helpful.

I have one question -

why is normative language not used in section 4.1 specially in the following section?

"if the data is to be sent via some other transport, a transport encoding suitable for that transport should be used instead of Base45. It is not recommended to first encode data in Base45 and then encode the resulting string in for example Base64 if the data is to be sent via email. Instead the Base45 encoding should be removed, and the data itself should be encoded in Base64." 

I find this recommendations are very important for the realisation of this protocol.