diff --git a/proposal.txt b/proposal.txt
index 0307e84..6a63ac2 100644
--- a/proposal.txt
+++ b/proposal.txt
@@ -125,15 +125,16 @@ the maximal "uxn1" header size (assuming all strings are maximum
 length and using an icon format of x0a3) would be 5904 bytes. while
 this is substantial it is unlikely to push most rom sizes over 64k
 (the point at which working with them from within varvara becomes
-annoying). since the maximum rom data size is 65280, authors are free
-to use up to 255 bytes of metadata while still keeping the total rom
-size under 65536.
+annoying). since the maximum rom data size is 65280, authors are
+guaranteed to be able to use up to 255 bytes of metadata while still
+keeping the total rom size under 65536 even if they are using the
+maximum amount of rom data.
 
 TEXT FORMATS
 
 uxn isn't likely to ever support unicode very well, so why did i write
 ASCII/UTF-8 for text formats? my take is that the text in roms is
-likely to be used both by uxn but also by exeternal systems that
+likely to be used both by uxn but also by external systems that
 probably _can_ handle UTF-8. i expect most authors to stick to the
 ASCII subset that uxn can handle.
 
@@ -144,12 +145,12 @@ we have some alternatives to consider:
  (c) mandate another particular encoding (latin-1)
  (d) leave the behavior of 8-bit values (0x80 - 0xff) unspecified
 
-i don't think (a) has any advantages of UTF-8 (uxn programs will still
-need to ignore 8-bit inputs in either case). option (b) sounds like a
-nightmare from within uxn programs and outside varvara UTF-8 is about
-as general as we really need to be in my opinion. option (c) doesn't
-feel much better than just limiting ourselves to ASCII (but maybe
-that's my own cultural bias speaking) and (d) sounds like a nightmare.
+i don't think (a) has any advantages over UTF-8 (uxn programs will
+still need to ignore 8-bit inputs in either case). option (b) sounds
+like a nightmare from within uxn programs and outside varvara UTF-8 is
+about as general as we really need to be (in my opinion). option (c)
+doesn't feel better than just limiting ourselves to ASCII (but maybe
+that's my own cultural bias speaking) and (d) sounds like total chaos.
 so my take is that inside varvara only ASCII values are likely to be
 well-supported, but for display outside varvara UTF-8 feels like the
 best option (e.g. allowing author's to write their names correctly).
@@ -168,8 +169,8 @@ strings and icon data and produces a full-featured "uxn1" rom.
 
 additionally it would be fairly easy to write tools to extract the
 metadata from roms into other formats that are easy for external tools
-to work with (e.g. PNG or BMP for icons, JSON or TXT for metadata,
-etc.)
+to consume and work with (e.g. PNG or BMP for icons, JSON or TXT for
+metadata, etc.)
 
 CONCLUSION
 
@@ -180,6 +181,7 @@ dividends as we move forward. among other things, it will:
  - display what license or copyright covers a rom
  - let users reliably determine which rom version is newest
  - allow launchers to display nice images and names
+ - make it easier to produce online catalogs of uxn roms
  - provide dates, places, and other historical info
  - let authors to write dedications or nice messages