>> can you please rename the production to something which is clearly not a
>> base64 string.
> HTTPbis describes the production as:
>
> "The "b64token" syntax allows the 66 unreserved URI characters
> ([RFC3986]), plus a few others, so that it can hold a base64, base64url
> (URL and filename sa
Hi Russ,
On 2012-07-17, at 19:06, Russ Housley wrote:
> I think you missed my point. In a PKI, when the issuer significantly changes
> the policy, subsequent certificates have a different policy identifier. I do
> not see a similar concept here.
You're right, I did miss your point, quite tho
Joe:
I think you missed my point. In a PKI, when the issuer significantly changes
the policy, subsequent certificates have a different policy identifier. I do
not see a similar concept here.
Russ
On Jul 16, 2012, at 6:33 PM, Joe Abley wrote:
> Hi Russ,
>
> On 2012-07-15, at 11:39, Russ Ho
On 7/17/12 5:14 PM, John C Klensin wrote:
--On Tuesday, July 17, 2012 13:57 -0500 Pete Resnick
wrote:
Perhaps I'm just being contrarian today, but I *do* think this
document should be BCP and not Informational. It is not a
requirements document in the sense that it is laying out
requirem
--On Tuesday, July 17, 2012 13:57 -0500 Pete Resnick
wrote:
> Perhaps I'm just being contrarian today, but I *do* think this
> document should be BCP and not Informational. It is not a
> requirements document in the sense that it is laying out
> requirements for future protocol documents being
On 7/3/12 7:51 AM, Eggert, Lars wrote:
On Jul 3, 2012, at 14:24, Alexey Melnikov wrote:
I found it is to be odd to have a requirements document as a BCP, but I am sure
you can sort the right status out with IESG.
+1
I fail to see why Informational wouldn't be the better status.
Lars
On 2012-07-17 20:03, Julian Reschke wrote:
On 2012-07-17 19:54, Mike Jones wrote:
The change and the reason for it were called out to the working group
in http://www.ietf.org/mail-archive/web/oauth/current/msg09594.html.
Indeed, as fait accompli. There were four days between the telco and the
On 2012-07-17 20:01, Mike Jones wrote:
You should actually probably make that name change request to the HTTPbis
working group. I suspect that if they decide to change the name, that we could
direct the RFC editor to make the same name change as HTTPbis does.
...
HTTPbis describes the produc
On 2012-07-17 19:54, Mike Jones wrote:
The change and the reason for it were called out to the working group in
http://www.ietf.org/mail-archive/web/oauth/current/msg09594.html.
Indeed, as fait accompli. There were four days between the telco and the
publication of the new draft for actually
You should actually probably make that name change request to the HTTPbis
working group. I suspect that if they decide to change the name, that we could
direct the RFC editor to make the same name change as HTTPbis does.
-- Mike
-Original Message-
From:
On 17/07/2012 18:15, Mike Jones wrote:
For clarity of discussion, the definition in question is:
b64token= 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
Note that b64token is a liberal syntax intended to permit base64 encoded content (hence the in
The change and the reason for it were called out to the working group in
http://www.ietf.org/mail-archive/web/oauth/current/msg09594.html.
What additional text would you propose that the RFC editor add to explain the
deviance from RFC 2617?
Thanks,
On 2012-07-17 19:39, Mike Jones wrote:
Yes, the decision to remove normative references to HTTPbis was made during the
public OAuth status call on Monday, July 9th, as the call participants wanted
to be able to publish the RFC before HTTPbis is published as an RFC.
Well, it would have been ni
Yes, the decision to remove normative references to HTTPbis was made during the
public OAuth status call on Monday, July 9th, as the call participants wanted
to be able to publish the RFC before HTTPbis is published as an RFC.
The sense on that call was that HTTPbis wouldn't be an RFC until near
On 2012-07-17 19:15, Mike Jones wrote:
For clarity of discussion, the definition in question is:
b64token= 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
Note that b64token is a liberal syntax intended to permit base64 encoded content (hence the in
For clarity of discussion, the definition in question is:
b64token= 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
Note that b64token is a liberal syntax intended to permit base64 encoded
content (hence the inclusion of the "+" and "/" characters and
On 17/07/2012 17:40, Julian Reschke wrote:
On 2012-07-17 18:10, Mike Jones wrote:
FYI, the b64 token definition is identical to the one in
draft-ietf-httpbis-p7-auth-20. If it works there, it should work for
OAuth Bearer.
...
+1; not every constraint needs to be expressed in the ABNF. "b64tok
On 2012-07-17 18:10, Mike Jones wrote:
FYI, the b64 token definition is identical to the one in
draft-ietf-httpbis-p7-auth-20. If it works there, it should work for
OAuth Bearer.
...
+1; not every constraint needs to be expressed in the ABNF. "b64token"
is here so recipients can parse the hea
FYI, the b64 token definition is identical to the one in
draft-ietf-httpbis-p7-auth-20. If it works there, it should work for OAuth
Bearer.
-- Mike
From: Stephen Farrell
Sent: 7/17/2012 4:12 AM
To: draft-ietf-oauth-v2-bearer@tools.ietf.org
Cc: General Area
Folks. Please don't develop any new revisions for these
documents right now. I know you can't officially post
'em anyway, but I don't want us to get tempted to roll
new versions handling unrelated comments. (Alexey's
comments are not unrelated.)
I'd like to handle any tweaks needed as RFC editor
I am still Ok with -22, but I have 1 new comment raised by introduction
of the base64 ABNF non terminal:
I think it would be worth adding a comment for b64token that points to
the base64 RFC. The current ABNF is too permissive (arbitrary number of
"=" allowed at the end) and there are enough b
My favourite typo was fixed in -08 ;-), my comment on REQ 10 was replied
to and I am still undecided on the document status (IESG should
decided), so this document is Ok for publication as far as I am concerned.
On 03/07/2012 13:24, Alexey Melnikov wrote:
I am the assigned Gen-ART reviewer for
Just to confirm: my comments on -14 were addressed in -17. I think this
is ready for publication now.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
On 12/05/2012 03:03, ssakane wrote:
Alexey,
Hi Shoichi,
Sorry, I've missed this email earlier. I just reviewed -17 and it is a
big improvement. I am more or less happy with it.
Thank you for your review and comments.
Firstly, I really apologize that my response has been delayed.
I had some
Please see attached review.
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Docu
25 matches
Mail list logo
