Re: Running code, take 2

--On Friday, December 14, 2012 10:49 +0200 Yaron Sheffer wrote: >... > The value in a 3933 experiment is in the Summary Report, > otherwise I agree it's a waste of time. At the end of the > period we will have a little bit of data to understand whether > we have traction for this idea, and whe

The notion of "fast tracking" drafts (was: Re: Running code, take 2)

Hi. I've been trying to say out of this because I think most of the suggestions are better carried out by AD-encouraged experiments and reports to the rest of us on effectiveness rather than by long discussions in the community about details and the costs of an unnecessary consensus process. How

Re: Last Call: (JSON Patch) to Proposed Standard

I wrote previously : > "4.1 add" bullet 3 reads (when completing the introductory sentence) > > ... the target location MUST reference ... > o An element to add to an existing array. > > I think this is incorrect; the target location is the array and the "value" > is the "element to add t

Re: Last Call: (JSON Patch) to Proposed Standard

"4.4. move" states The target location MUST NOT be part of the location defined by "from"; i.e., a location cannot be moved into one of its children. This constraint is backwards. I.e. to disallow moving into a child, { "op": "move", "from": "/a/b/c", "path": "/a/b/c/d" } this should

draft-ietf-appsawg-json-pointer-07 - array index for end ofarray

I originally posted this in a "Re: Last Call: (JSON Patch) to Proposed Standard" thread but now I've read draft-ietf-appsawg-json-pointer-07 and have changed that suggestion to reflect draft-ietf-appsawg-json-pointer-07 Suggestion: allow negative numbers to indicate a position counted from the

Re: Last Call: (JSON Patch) to Proposed Standard

Can one add elements of array to an array? E.g. given the document { "a" : { "b" : [ "red", "green" ] } } If I want to add two values to an existing array, I can use [ { "op": "add", "path": "/a/b/-", "value": "blue" }, { "op": "add", "path": "/a/b/-", "value": "yellow" } ] (I found in th

Re: Last Call: (JSON Patch) to Proposed Standard

"4.1 add" and "4.2 remove" refers to "specified index", but I do not see name of the index member specified in the draft, or how to represent it. (Other sections are more explicit, i.e. "from" for the "move" op.) i.e. "index" as in "index" : integer The phrasing If the "-" character i

Re: Last Call: (JSON Patch) to Proposed Standard

"4.1 add" bullet 3 reads (when completing the introductory sentence) ... the target location MUST reference ... o An element to add to an existing array. I think this is incorrect; the target location is the array and the "value" is the "element to add to an existing array". I suggest: ...

Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard

How so? Doesn't appear to be a problem in practice. On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler wrote: > Hmm.. I think that’s quite problematic. Especially considering how JSON > Pointer is used in JSON Patch. > > ** ** > > ** ** > > -- > > Markus Lanthaler > > @markuslanthaler

Re: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard

JSON Pointer does not distinguish between objects and arrays. That is not determined until the pointer is applied to an actual object instance... the pointer "/1" is valid against {"1":"a"} or ["a","b"] On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler wrote: > I've asked that before but didn't

Re: Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

Yep, could do it soon later. Currently, I suggest a modification for "The token service is the assertion issuer; its role is to fulfill requests from clients, which present various credentials, and mint assertions as requested, fill them with appropriate information, and sign them." (in

Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

Correct. That said no one has yet profiled it for holder of key - cmort On Dec 13, 2012, at 6:39 PM, "zhou.suj...@zte.com.cn" mailto:zhou.suj...@zte.com.cn>> wrote: Oh, But the description of assertion generation in the document should not be limited by bear

RE: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard

Hmm.. I think that’s quite problematic. Especially considering how JSON Pointer is used in JSON Patch. -- Markus Lanthaler @markuslanthaler From: James M Snell [mailto:jasn...@gmail.com] Sent: Friday, December 14, 2012 5:41 PM To: Markus Lanthaler Cc: IETF Discussion; IETF Apps

Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

FYI, I have been writing HoK for JWT/JWS Token by introducing a new claim 'cid'. =nat via iPhone Dec 14, 2012 11:56、"zhou.suj...@zte.com.cn" のメッセ�`ジ: Yep, could do it soon later. Currently, I suggest a modification for "The token service is the assertion issuer; its role is to fulfill requ

RE: [apps-discuss] Last Call: (JSON Pointer) to Proposed Standard

I've asked that before but didn't get an answer. So let me ask again (even though I'm quite sure it has already been asked by somebody else). How does JSON Pointer distinguish between objects and arrays? E.g. consider the following JSON document: { "foo": "bar", "1": "baz" } As I read the dr

Re: Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

Oh, But the description of assertion generation in the document should not be limited by bear assertion, right? Chuck Mortimore 写于 2012-12-14 10:34:13: > You want a holder of key pattern. The draft touches on it > > >The protocol parameters and processing rules defined in this document

Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

You want a holder of key pattern. The draft touches on it The protocol parameters and processing rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. The use of holder-of-key assertions are not precluded by this

Re: Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

I am not sure if the following usecase http://www.ietf.org/mail-archive/web/oauth/current/msg10233.html could be supported by assertion framework， We have some discussion in http://www.ietf.org/mail-archive/web/oauth/current/msg10203.html http://www.ietf.org/mail-archive/web/oauth/current/msg1019

Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

On Dec 13, 2012, at 4:30 PM, "zhou.suj...@zte.com.cn" mailto:zhou.suj...@zte.com.cn>> wrote: From the language, I got an impression that assertion is only generated by token service after clients presenting some credentials, there are may be some cases that "ass

Re: Re: [OAUTH-WG] Last Call: (Assertion Framework for OAuth 2.0) to Proposed Standard

From the language, I got an impression that assertion is only generated by token service after clients presenting some credentials, there are may be some cases that "assertion" don't need client's credential. e.g., Resource owner as a token service could generate "assertion" to a client he trus

Re: Running code, take 2

Hi Tom, I am myself somewhat puzzled by the current process, where such information is gathered prior to IESG review, because (in my limited experience) I have never seen the IESG reject a draft merely because it is unimplemented. In any case, my proposal aims to move the burden to authors,

Re: Running code, take 2

Hi Yaron, I'm glad to see more discussion of this general topic. On 12/12/2012 07:31 PM, Yaron Sheffer wrote: > Hi, > > I have just published a draft that proposes an alternative to Stephen's > "fast track". My proposal simply allows authors to document, in a > semi-standard way, whatever imple

Re: Running code, take 2

On Fri, Dec 14, 2012 at 1:36 PM, Alessandro Vesely wrote: > On Fri 14/Dec/2012 09:49:30 +0100 Yaron Sheffer wrote: >> >> to clarify, my proposal only applies to Internet Drafts, and clearly >> states that the implementation section should be removed from the >> document before it is published as R

Re: Running code, take 2

Hi Randy, I don't know who's "we" in your question. My proposal is aimed at an earlier stage in the process, when the WG needs to evaluate a draft before it becomes a WG document and later, during WGLC. During these stages, information about implementation status is very useful, even if (as s

Re: Running code, take 2

On Fri 14/Dec/2012 09:49:30 +0100 Yaron Sheffer wrote: > > to clarify, my proposal only applies to Internet Drafts, and clearly > states that the implementation section should be removed from the > document before it is published as RFC. One place where an Implementation Status may help is IETF L

Re: Running code, take 2

> I am surprised at this. Gathering information about implementations is > something that happens in some WGs and not in others, but it is always > the chair that is driving it, often as part of the write-up prior to > IETF Last Call. uh, not really. in some wg cultures, it's just seen as part o

Re: Running code, take 2

> to clarify, my proposal only applies to Internet Drafts, and clearly > states that the implementation section should be removed from the > document before it is published as RFC. > > Formally, we don't want non-permanent stuff in RFCs. And realistically, > even if we had an implementation wik

Re: Running code, take 2

- Original Message - From: "Marc Blanchet" To: "Loa Andersson" Cc: Sent: Thursday, December 13, 2012 3:39 PM Le 2012-12-13 à 10:22, Loa Andersson a écrit : > Folks, > > I agree that understanding the implementation status of a draft > sometimes is essential, but not for all drafts and n

Re: Running code, take 2

- Original Message - From: "Yaron Sheffer" To: Cc: ; "'Alessandro Vesely'" Sent: Thursday, December 13, 2012 2:52 PM > Hi Adrian, > > I would suggest to start with my proposal, because it requires zero > implementation effort. I am surprised at this. Gathering information about impleme

Re: Running code, take 2

Hi John, to clarify, my proposal only applies to Internet Drafts, and clearly states that the implementation section should be removed from the document before it is published as RFC. Formally, we don't want non-permanent stuff in RFCs. And realistically, even if we had an implementation wik