John Cowan:
...
> For "We encourage implementations to *always* implement curly-infix
> expressions" read "Implementations SHOULD implement c-expressions".

Done.

> For "Applications should" read "Applications SHOULD".

Waiting to see if there are other comments on the MUST/SHOULD markers.

> For "We recommend that portable applications do *not*" read "Applications
> SHOULD NOT".

Done.

> For "We encourage implementations' *default* invocation" read "An
> implementation's default implementation SHOULD", and remove ", but this
> is not required".

Done.

> As mentioned earlier, remove the sentence about "curly-foo"

Plan to; want to see if there are other comments.

> What is said about defining "nfx" should also be said about
> "$bracket-access$".

Done.

> For "(curly-infix-read . port)" read something like "curly-infix-read
> with an optional port argument.

Done.  I used [port] instead of ". port".

> Add the following boilerplate to the top of the specification:
>
>       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>       "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL"
>       in this document are to be interpreted as described in RFC 2119.

Done.

> I recommend the use of small capital letters rather than
> italics for these key words: this can be achieved in HTML with
> <small>MUST</small>, <small>SHOULD</small>, etc.  or in HTML/CSS with
> <span style="font-variant: small-caps;">must</span>, etc.

Currently leaning towards <em>SHOULD</em> instead of <small>...</small>, due to concerns about what <small> might do, but I'm curious what others say.

--- David A. Wheeler