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

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 13 Jun 2013 18:04:41 +0000

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 13 Jun 2013 11:43:38 -0700

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
[email-masked]

On 2013-06-13, at 11:04 AM, Karen O'Donoghue wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Thu, 13 Jun 2013 15:31:20 -0400

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-masked]>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
>

---

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 13 Jun 2013 21:00:45 +0000

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-masked]<mailto:[email-masked]>> wrote:
Folks,

Regards,
Karen

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose