Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

2016-02-24 Thread sakimura 
The link relations registry is a regular IANA registry, just like OAuth 
parameters registry.
It is also available in XML format but so is the OAuth parameters 
registry, i.e.:


http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml

You do not say that OAuth is XML based because the parameter registry is 
available also in XML, do you?


# OTHT, it would be an interesting idea to suggest to IANA to make
# those registries available in JSON as well.

Nat

2016-02-25 06:06 に Anthony Nadalin さんは書きました:

So as I understand it in the Link Relations repository are XML
documents that one has to create, are you suggesting as part of this
effort is to rewrite all that in JSON and make a proposal for that
also ?

FROM: Nat Sakimura [mailto:sakim...@gmail.com]
 SENT: Tuesday, February 16, 2016 4:55 PM
 TO: Anthony Nadalin ; oauth 
 SUBJECT: Re: [OAUTH-WG] Fwd: New Version Notification for
draft-sakimura-oauth-meta-07.txt

Link relation is not at all XML. It is a step forward to RESTfulness.

In the older version of the draft, I was using JSONized version of it
as well, but I splitted it out for the sake of brevity.

It is all about dynamic metadata about the response.

Once we do it with RFC5988, we could easily create a parallel to it
with JSON meta object of your flavour.

(Currently, JSON schema seems to be in fashion, though I personally
prefer HAL.)

Good things about using JSONized version is that it will be usable
outside the HTTP and the fact that it can be stored in a single JSON
object together with the data.

Bad thing about it is that we have to start from the syntax for it,
which we can avoid by using RFC5988.

If people want the JSON version of this, I could do it as well.

However, since we are processing HTTP response headers anyways, there
is not much compelling reason for that as long as we stick with HTTP.

That's why I am just sticking with RFC5988.

Nat.

2016年2月17日(水) 8:50 Anthony Nadalin :


I really think that this is a step backwards relative to technology
and what the developers would accept. The Link Relations takes us
back to the XML days, I thought we have all moved on from that and
at least trying to move Oauth to JSON. I think if this were adopted
we might be splitting the developers into folks that are already
going down the current JSON path with Oauth and those that want to
go back to XML.

This just seems a very odd draft to adopt this technology.

FROM: OAuth [mailto:oauth-boun...@ietf.org] ON BEHALF OF Nat
Sakimura
SENT: Monday, February 15, 2016 3:59 PM
TO: oauth 
SUBJECT: [OAUTH-WG] Fwd: New Version Notification for
draft-sakimura-oauth-meta-07.txt

It now shows how to return multiple endpoints in web linking.

Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: 
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for
draft-sakimura-oauth-meta-07.txt
To: Nov Matake , Nat Sakimura ,
Sascha Preibisch , Sascha Preibisch


A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name: draft-sakimura-oauth-meta
Revision: 07
Title: OAuth Response Metadata
Document date: 2016-02-12
Group: Individual Submission
Pages: 10
URL:


https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt

[1]
Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
[2]
Htmlized: https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
[3]
Diff:
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07 [4]

Abstract:
This specification defines an extensible metadata that may be
inserted into the OAuth 2.0 responses to assist the clients to
process those responses. It is expressed either as a link header,
or
query parameters. It will allow the client to learn where the
members in the response could be used, what is the characteristics
of
the payload is, how it should be processed, and so on. Since they
are just additional response header/query parameters, any client
that
does not understand this extension should not break and work
normally
while supporting clients can utilize the metadata to take the
advantage of the extension.

Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org
[5].

The IETF Secretariat



Links:
--
[1]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-sakimura-oauth-meta-07.txt&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6M10Q9X4cq%2b%2fRroR%2fHYQ9IN3P1HO06JnbuzY6P3oWtc%3d
[2]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-sakimura-oauth-meta%2f&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7twEM0FztSaswtFiYslvJuadTyWbWRSDWQ6uT%2bevKw

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

2016-02-24 Thread Anthony Nadalin 
So as I understand it in the Link Relations repository are XML documents that 
one has to create, are you suggesting as part of this effort is to rewrite all 
that in JSON and make a proposal for that also ?

From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Tuesday, February 16, 2016 4:55 PM
To: Anthony Nadalin ; oauth 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

Link relation is not at all XML. It is a step forward to RESTfulness.
In the older version of the draft, I was using JSONized version of it as well, 
but I splitted it out for the sake of brevity.
It is all about dynamic metadata about the response.
Once we do it with RFC5988, we could easily create a parallel to it with JSON 
meta object of your flavour.
(Currently, JSON schema seems to be in fashion, though I personally prefer HAL.)
Good things about using JSONized version is that it will be usable outside the 
HTTP and the fact that it can be stored in a single JSON object together with 
the data.
Bad thing about it is that we have to start from the syntax for it, which we 
can avoid by using RFC5988.
If people want the JSON version of this, I could do it as well.
However, since we are processing HTTP response headers anyways, there is not 
much compelling reason for that as long as we stick with HTTP.
That's why I am just sticking with RFC5988.

Nat.


2016年2月17日(水) 8:50 Anthony Nadalin 
mailto:tony...@microsoft.com>>:
I really think that this is a step backwards relative to technology and what 
the developers would accept. The Link Relations takes us back to the XML days, 
I thought we have all moved on from that and at least trying to move Oauth to 
JSON. I think if this were adopted we might be splitting the developers into 
folks that are already going down the current JSON path with Oauth and those 
that want to go back to XML.

This just seems a very odd draft to adopt this technology.

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Nat Sakimura
Sent: Monday, February 15, 2016 3:59 PM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake mailto:n...@matake.jp>>, Nat Sakimura 
mailto:sakim...@gmail.com>>, Sascha Preibisch 
mailto:sascha.preibi...@gmail.com>>, Sascha 
Preibisch mailto:sascha.preibi...@gmail.com>>



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-meta
Revision:   07
Title:  OAuth Response Metadata
Document date:  2016-02-12
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-sakimura-oauth-meta-07.txt&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6M10Q9X4cq%2b%2fRroR%2fHYQ9IN3P1HO06JnbuzY6P3oWtc%3d>
Status: 
https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-sakimura-oauth-meta%2f&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7twEM0FztSaswtFiYslvJuadTyWbWRSDWQ6uT%2bevKwM%3d>
Htmlized:   
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kh2nH4IyNm3OAA5nkrSFzZN16Xic%2b2EDUOfr%2fG6CjVY%3d>
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ICtk5U1e6kBPFI8ov0n06TAcqDX3HurgFTydXKD73Yo%3d>

Abstract:
   This specification defines an extensible metadata that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a link header, or
   query parameters.  It will allow the client to learn where the
   members in the response could be used, what is the characteristics of
   the payload i

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

2016-02-16 Thread Nat Sakimura 
Link relation is not at all XML. It is a step forward to RESTfulness.
In the older version of the draft, I was using JSONized version of it as
well, but I splitted it out for the sake of brevity.
It is all about dynamic metadata about the response.
Once we do it with RFC5988, we could easily create a parallel to it with
JSON meta object of your flavour.
(Currently, JSON schema seems to be in fashion, though I personally prefer
HAL.)
Good things about using JSONized version is that it will be usable outside
the HTTP and the fact that it can be stored in a single JSON object
together with the data.
Bad thing about it is that we have to start from the syntax for it, which
we can avoid by using RFC5988.
If people want the JSON version of this, I could do it as well.
However, since we are processing HTTP response headers anyways, there is
not much compelling reason for that as long as we stick with HTTP.
That's why I am just sticking with RFC5988.

Nat.


2016年2月17日(水) 8:50 Anthony Nadalin :

> I really think that this is a step backwards relative to technology and
> what the developers would accept. The Link Relations takes us back to the
> XML days, I thought we have all moved on from that and at least trying to
> move Oauth to JSON. I think if this were adopted we might be splitting the
> developers into folks that are already going down the current JSON path
> with Oauth and those that want to go back to XML.
>
>
>
> This just seems a very odd draft to adopt this technology.
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura
> *Sent:* Monday, February 15, 2016 3:59 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] Fwd: New Version Notification for
> draft-sakimura-oauth-meta-07.txt
>
>
>
> It now shows how to return multiple endpoints in web linking.
>
> Also, added Resource Endpoint response header.
>
>
>
> Best,
>
>
>
> nat
>
>
>
> -- Forwarded message -
> From: 
> Date: 2016年2月12日(金) 18:40
> Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
> To: Nov Matake , Nat Sakimura , Sascha
> Preibisch , Sascha Preibisch <
> sascha.preibi...@gmail.com>
>
>
>
>
> A new version of I-D, draft-sakimura-oauth-meta-07.txt
> has been successfully submitted by Nat Sakimura and posted to the
> IETF repository.
>
> Name:   draft-sakimura-oauth-meta
> Revision:   07
> Title:  OAuth Response Metadata
> Document date:  2016-02-12
> Group:  Individual Submission
> Pages:  10
> URL:
> https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-sakimura-oauth-meta-07.txt&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6M10Q9X4cq%2b%2fRroR%2fHYQ9IN3P1HO06JnbuzY6P3oWtc%3d>
> Status:
> https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-sakimura-oauth-meta%2f&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7twEM0FztSaswtFiYslvJuadTyWbWRSDWQ6uT%2bevKwM%3d>
> Htmlized:   https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kh2nH4IyNm3OAA5nkrSFzZN16Xic%2b2EDUOfr%2fG6CjVY%3d>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ICtk5U1e6kBPFI8ov0n06TAcqDX3HurgFTydXKD73Yo%3d>
>
> Abstract:
>This specification defines an extensible metadata that may be
>inserted into the OAuth 2.0 responses to assist the clients to
>process those responses.  It is expressed either as a link header, or
>query parameters.  It will allow the client to learn where the
>members in the response could be used, what is the characteristics of
>the payload is, how it should be processed, and so on.  Since they
>are just additional response header/query parameters, any client that
>does not understand this extension should not break and work normally
>while supporting clients can utilize the metadata to take the
>advantage of the extension.
>
>

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

2016-02-16 Thread Anthony Nadalin 
I really think that this is a step backwards relative to technology and what 
the developers would accept. The Link Relations takes us back to the XML days, 
I thought we have all moved on from that and at least trying to move Oauth to 
JSON. I think if this were adopted we might be splitting the developers into 
folks that are already going down the current JSON path with Oauth and those 
that want to go back to XML.

This just seems a very odd draft to adopt this technology.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Monday, February 15, 2016 3:59 PM
To: oauth 
Subject: [OAUTH-WG] Fwd: New Version Notification for 
draft-sakimura-oauth-meta-07.txt

It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake mailto:n...@matake.jp>>, Nat Sakimura 
mailto:sakim...@gmail.com>>, Sascha Preibisch 
mailto:sascha.preibi...@gmail.com>>, Sascha 
Preibisch mailto:sascha.preibi...@gmail.com>>



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-meta
Revision:   07
Title:  OAuth Response Metadata
Document date:  2016-02-12
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2finternet-drafts%2fdraft-sakimura-oauth-meta-07.txt&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6M10Q9X4cq%2b%2fRroR%2fHYQ9IN3P1HO06JnbuzY6P3oWtc%3d>
Status: 
https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-sakimura-oauth-meta%2f&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7twEM0FztSaswtFiYslvJuadTyWbWRSDWQ6uT%2bevKwM%3d>
Htmlized:   
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kh2nH4IyNm3OAA5nkrSFzZN16Xic%2b2EDUOfr%2fG6CjVY%3d>
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2frfcdiff%3furl2%3ddraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ICtk5U1e6kBPFI8ov0n06TAcqDX3HurgFTydXKD73Yo%3d>

Abstract:
   This specification defines an extensible metadata that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a link header, or
   query parameters.  It will allow the client to learn where the
   members in the response could be used, what is the characteristics of
   the payload is, how it should be processed, and so on.  Since they
   are just additional response header/query parameters, any client that
   does not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to take the
   advantage of the extension.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org&data=01%7c01%7ctonynad%40microsoft.com%7c3a992d5ff4a2428804f208d336641292%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aijC6rAn01n04mDyB5lpV7tQitxIyf0drdheleR955A%3d>.

The IETF Secretariat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

2016-02-15 Thread Nat Sakimura 
It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: 
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake , Nat Sakimura , Sascha
Preibisch , Sascha Preibisch <
sascha.preibi...@gmail.com>



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-meta
Revision:   07
Title:  OAuth Response Metadata
Document date:  2016-02-12
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt
Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
Htmlized:   https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
Diff:
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07

Abstract:
   This specification defines an extensible metadata that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a link header, or
   query parameters.  It will allow the client to learn where the
   members in the response could be used, what is the characteristics of
   the payload is, how it should be processed, and so on.  Since they
   are just additional response header/query parameters, any client that
   does not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to take the
   advantage of the extension.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth