Re: [jose] thoughts on deployed code and breaking changes

[Phil Hunt <[e-mail]>]

When I hear arguments like we can't consider BSON because it requires breaking changes, the hair on the back of my neck raises. If BSON support requires breaking change now, than it can NEVER be supported down the road. To me that makes the issue an omission.  

Per section 4.1.1 of RFC2026:
>    A Proposed Standard should have no known technical omissions with
>    respect to the requirements placed upon it.  However, the IESG may
>    waive this requirement in order to allow a specification to advance
>    to the Proposed Standard state when it is considered to be useful and
>    necessary (and timely) even with known technical omissions.

I think there has been *some* discussion on the issue. But far too many do not want to discuss because of the possibility of breaking change, so no conclusion can be made as to whether this is an omission or not.

Finally, while the drafts are relatively stable, we are not officially stable. Anyone implementing now should know this. I point out that the drafts have not been approved as PROPOSED STANDARD yet, so changes should be expected.

Again, I have no opinion on this issue, but I am concerned about the lack of on-topic discussion.  Size has always been a major driving factor in the JOSE discussion. It does seem on topic to me that the B64 support method for binary doesn't meet the design criteria that has been used regarding small size. I don't necessarily think binary has to be solved now. But important questions must be discussed.

Is there a way binary can be supported?  Can BSON be delayed into a future draft without breaking the current drafts?  If there is any sense of breaking changes, NOW is the time to make those changes - not later.

Finally, I was surprised to learn that 2026 doesn't even require deployed code in PROPOSED STANDARD. That just points out that these drafts are still incredibly *early* in their design despite assertions of stability.  The fact that many are in production doesn't mean the process gets skipped. We cannot assume DRAFT STANDARD status when we aren't even at PROPOSED STANDARD status.

Phil

@independentid
www.independentid.com
[e-mail]





On 2013-06-13, at 11:04 AM, Karen O'Donoghue 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose