Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-18.txt

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Dec 2014 17:17:18 -0500 (EST)

On Tue, 25 Nov 2014, [email-masked] wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.
>
>         Title           : A set of SASL Mechanisms for OAuth
>         Authors         : William Mills
>                           Tim Showalter
>                           Hannes Tschofenig
> 	Filename        : draft-ietf-kitten-sasl-oauth-18.txt
> 	Pages           : 22
> 	Date            : 2014-11-25
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-18

I looked at the diff and the full document, and don't have any substantive
concerns with my individual hat.

Some nits that will need fixing at some point in the process:

* SASL (and all acronyms, but that's what I noticed) should be expanded at
its first use, not the second use.

* The Gen-ART reviewer may well ask why Figure 1 shows the authorization
request being made directly to the resource owner, when the preferred
workflow is for the authorization request to go through the authorization
server as an intermediary.

* Near the end of page 6, in the text describing the case where
authorization fails, s/finalizing a SASL negotiation,/finalizing a SASL
negotiation;/ (replace comma with semicolon to avoid comma splice)

* In section 3.1.1, is there an extra word in "For OAuth Access Token
Types that use request keyed message digest"?

Thanks for the updates.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Mon, 1 Dec 2014 23:56:02 +0000 (UTC)

So expand the acronym in the title?  I was spelling it out in the first use in the text.
Instead of using semicolon why not just make a new sentence?  s/finalizing a SASL negotiation, the additional/finalizing a SASL negotiation. The additional/
In 3.1.1 the wording is wrong.  I think "For OAuth Access Token Types that include a keyed message digest of the request the default values MUST be used  ..." is better.  Does that work for you?

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Dec 2014 13:12:49 -0500 (EST)

> So expand the acronym in the title?  I was spelling it out in the first use in

No, not in the title.  I think the text had changed so the expansion was
no longer the first use in the text.

   [...] This document
   integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications
   using the integration into SASL.  Hence, this document takes
                              ^^^^
   advantage of the OAuth protocol and its deployment base to provide a
   way to use the Simple Authentication and Security Layer (SASL)

> Instead of using semicolon why not just make a new sentence?  s/finalizing a SASL

That works, too :)

> In 3.1.1 the wording is wrong.  I think "For OAuth Access Token Types that
> include a keyed message digest of the request the default values MUST be used
>  ..." is better.  Does that work for you?

That works, thanks.

-Ben

---

From: Bill Mills <[email-masked]>
Date: Tue, 2 Dec 2014 18:31:47 +0000 (UTC)

My bad, I expand SASL both in the abstract and in the 3rd usage,   Leave the first expansion in the Abstract or do that as the first usage in the Introduction? 

     On Tuesday, December 2, 2014 10:12 AM, Benjamin Kaduk <[email-masked]> wrote:

  [...] This document

That works, too :)

That works, thanks.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Dec 2014 15:48:53 -0500 (EST)

On Tue, 2 Dec 2014, Bill Mills wrote:

> My bad, I expand SASL both in the abstract and in the 3rd usage,   Leave
> the first expansion in the Abstract or do that as the first usage in the
> Introduction?

I think it's best to consider the abstract as a separate creature
entirely, and try to not use acronyms at all in it.

Acronyms can be used in the main text, and should be expanded at the first
use in the main text.

It looks like the RFC style guide doesn't say anything about acronyms, so
maybe I am not speaking from any authority here.

-Ben

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 03 Dec 2014 12:23:33 +0000

> entirely, and try to not use acronyms at all in it.
This is true. Although Acronyms, if used, need to be expanded in the 
Abstract.