To be clear, I didn't declare an embargo on breaking changes. I just set what I believe to be a reasonable metric at this stage of the spec development as "strong rationale and a ground swell of working group support". I would imagine that said working group support would be easier to achieve for the JSON serializations than the compact serializations.
I'm also trying to ensure that every thing under consideration is on the table. There is a time for more open ended conversations, and there is a time to ship what is done. While I don't think these are the only considerations, I do think we need to be mindful of the amount of time spent on this thus far, the external standards efforts looking to the results of this work, and the currently deployed implementations. Please, I urge everyone, review the latest specs. If there are needed changes, provide a strong rationale and clear concise text for the documents ASAP. Karen On 6/13/13 3:31 PM, Richard Barnes wrote: Could we at least clarify that the embargo on breaking changes is to the *compact* serialization of *JWS*? All of the backward compatibility concerns we've heard are for JWT, which is primarily based on JWS. And as far as I know, there's been no implementation of the JSON serializations yet, so we don't have the same compatibility burden. I don't mean to imply that I've got a bunch of horrible stuff queued up. I'm as interested in getting this done as the next guy. I just want to make clear that things like ISSUE-20 and Jim's suggestion on unencoded protected headers are not ruled out of bounds. --Richard On Thu, Jun 13, 2013 at 2:04 PM, Karen O'Donoghue <[email protected]<mailto:[email protected]>> wrote: Folks, I *personally* believe the time for major breaking changes is past for this version of the specification. I believe we are now in the phase of final corrections and minor tweaks for a v1.0. We scheduled an interim meeting in April to get all remaining issues on the table and discussed. These specifications have been evolving for a long time. I am sure that they could be improved in a myriad of ways, but at this point, without a strong rationale and a ground swell of working group support, we should work to complete what we have. Any major refactoring or new functionality should be deferred as future work. At that time, we can work to "break cleanly with existing code." We better serve the IETF and the broader community by getting these specifications out the door. We will have an interim teleconference Monday (with a few more possibly to follow) to review the implementation of the interim discussions and to discuss any final issues. I strongly encourage folks to review the specifications and the minutes of the interim with that in mind. Regards, Karen _______________________________________________ jose mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
