Subject: [apps-discuss] Fw: New Version Notification for draft-wmills-oauth-lrdd-02.txt

From: William Mills <[email-masked]>
Date: Tue, 25 Sep 2012 18:57:52 -0700 (PDT)

Hi all,

I've updated this individual draft with another example.  I'm not quite sure how to proceed though with an individual submission rather than a WG one, I don't think there's a lot left to be done.  I'd appreciate any comments, and guidance.

Thanks,

-bill

>
>
>
>----- Forwarded Message -----
>From: "[email-masked]" <[email-masked]>
>To: [email-masked] 
>Sent: Tuesday, September 25, 2012 6:38 PM
>Subject: New Version Notification for draft-wmills-oauth-lrdd-02.txt
> 
>
>A new version of I-D, draft-wmills-oauth-lrdd-02.txt
>has been successfully submitted by William J. Mills and posted to the
>IETF repository.
>
>Filename:     draft-wmills-oauth-lrdd
>Revision:     02
>Title:         Link Type Registry for OAuth 2
>Creation date:     2012-09-26
>WG ID:         Individual Submission
>Number of pages: 12
>URL:             http://www.ietf.org/internet-drafts/draft-wmills-oauth-lrdd-02.txt
>Status:          http://datatracker.ietf.org/doc/draft-wmills-oauth-lrdd
>Htmlized:        http://tools.ietf.org/html/draft-wmills-oauth-lrdd-02
>Diff:            http://www.ietf.org/rfcdiff?url2=draft-wmills-oauth-lrdd-02
>
>Abstract:
>   Defines link type registrations for the OAuth 2
 authentication
>   framework.
>The IETF Secretariat

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 26 Sep 2012 11:12:18 +0200

Hello bill,

Thanks for the update. I also believe this should be straightforward...

Some comments regarding your latest revision:

-          The page header still mentions "A SASL/GSS-API Mechanism for OAuth" and needs cleanup

-          Section 2: you mention "C:", "S:" and SASL terminology that are not used in the draft and need cleanup

-          4.1.2: /s/available/available (twice)

-          4.1.2: you mention "The client MAY use this to determine if the client supports ..." (for grant types and token types). Isn't it rather the client to determine whether the *server* support these grant types? What about "The client MAY use this to determine the grant/token types available at the server"?

-          5.1: maybe you could provide https endpoints in your example rather than http as this would be more typical/in line with oauth recommendations

-          5.2: /s/soupporting/supporting

-          6.2: note that the wf i-d is now wg (ietf-appsawg-webfinger-00)

In general I am not that clear about your representation of the "grant-types" and "token-types" properties/attributes in the examples. Based on rfc6415 xrd/jrd mapping there seem to be some inconsistency on the mapping: do you envision these as link attributes or as properties?

Cheers
walter

Da: [email-masked] [mailto:[email-masked]] Per conto di William Mills
Inviato: mercoledì 26 settembre 2012 3.58
A: Apps Discuss
Oggetto: [apps-discuss] Fw: New Version Notification for draft-wmills-oauth-lrdd-02.txt

Hi all,

Thanks,

-bill

----- Forwarded Message -----
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Sent: Tuesday, September 25, 2012 6:38 PM
Subject: New Version Notification for draft-wmills-oauth-lrdd-02.txt

Abstract:
  Defines link type registrations for the OAuth 2 authentication
  framework.

The IETF Secretariat

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: William Mills <[email-masked]>
Date: Wed, 26 Sep 2012 09:42:53 -0700 (PDT)

Thank you for the review!  Comments inline.

>________________________________
> From: Goix Laurent Walter <[email-masked]>
>To: William Mills <[email-masked]>; Apps Discuss <[email-masked]> 
>Sent: Wednesday, September 26, 2012 2:12 AM
>Subject: R: [apps-discuss] Fw: New Version Notification for draft-wmills-oauth-lrdd-02.txt
> 
>
> 
>Hello bill,
> 
>Thanks for the update. I also believe this should be straightforward…
> 
>-          The page header still mentions “A SASL/GSS-API Mechanism for OAuth” and needs cleanup
>-          Section 2: you mention “C:”, “S:” and SASL terminology that are not used in the draft and need cleanup

Fixed and fixed.

>-          4.1.2: /s/available/available (twice)

Only found one?

>-          4.1.2: you mention “The client MAY use this to determine if the client supports …” (for grant types and token types). Isn’t it rather the client to determine whether the *server* support these grant types? What about “The client MAY use this to determine the grant/token types available at the server”?

Changed the language, but not quite what you suggest.

>-          5.1: maybe you could provide https endpoints in your example rather than http as this would be more typical/in line with oauth recommendations

DOH!!!

>-          6.2: note that the wf i-d is now wg (ietf-appsawg-webfinger-00)

Fixed x2

> 
>In general I am not that clear about your representation of the “grant-types” and “token-types” properties/attributes in the examples. Based on rfc6415 xrd/jrd mapping there seem to be some inconsistency on the mapping: do you envision these as link attributes or as properties?
> 

These are link extensions as defined in rfc 5988.  I see that I've represented them wrong in XRD, fixing that.

>walter

Again, thanks!