Re: [secdir] SECDIR review of draft-ietf-httpbis-alt-svc-12

[Barry Leiba <[e-mail]>]

Thanks for the review, Chris.  A point on the Latin abbreviations:

> Each use of 'e.g.' should be followed by a comma. There seem to be some that
> aren't.
...
> There are a lot of parentheticals throughout. Putting an 'e.g.' or 'i.e.' in
> a sentence does not require that it be within parenthesis. Stick a comma in
> front it it and move on. ;-) Y'all almost did that within the last paragraph
> of Section 9.5 but didn't get it altogether right.

As it happens, I have a strong preference for avoiding "i.e." and
"e.g.", for a number of reasons.  One is that they're often not used
quite right, as you note in these two comments.  Another is that one
is often used when the other should be (that's not the case in this
document).  But the main one is that they're almost always
unnecessary, and removing them and/or rewording makes better sentences
-- "i.e." can almost always just be removed, and "e.g." can usually be
replaced with a more natural "such as", "as with", or something of
that sort.  An example of common misuse: "...as with fruit, e.g.,
apples, bananas, etc."  Euw!

>    When the protocol does not explicitly carry the scheme (e.g., as is
>    usually the case for HTTP/1.1 over TLS, servers can mitigate this
>    risk by either assuming that all requests have an insecure context,
>    or by refraining from advertising alternative services for insecure
>    schemes (such as HTTP).
>
> The first parenthetical is opened with a left parenthesis but closed with a
> comma. I'd suggest using commas to open and close that. The second should
> just be separated by a preceding comma. Best regards, Chris

Actually, this is a really good example where "e.g." isn't needed at
all (the "as is...the case" takes care of that), and where the
sentence works better this way (also correcting the non-parallel use
of "either", while we're here):

NEW
   When the protocol does not explicitly carry the scheme, as is
   usually the case for HTTP/1.1 over TLS, servers can mitigate this
   risk either by assuming that all requests have an insecure context,
   or by refraining from advertising alternative services for insecure
   schemes such as HTTP.
END

I urge the authors to make a quick run-through along with handling
other comments, and to get rid of as many of the "i.e."s and "e.g."s
as they reasonably can.

Barry