Elwyn: thank you for your careful review (as always!) of specifications. And thank you Tim and Paul considering the input.
But maybe a little bit of explanation about the role of Gen-ART review is in order. The IETF produces very high-quality specifications. The way that we achieve that is through multiple mechanisms, from having the expert people to careful WG processes and broad review. The Gen-ART reviews are exactly that, reviews. I use them as a way to decide if there are serious enough problems in the document that it warrants me to read it in more detail and/or possibly raise an issue in the IESG review. But they are also reviews, and have components (e.g. editorial suggestions) that document authors and working groups may consider and take into account. And often do. And the reviewers, being responsible, usually are willing to clarify and discuss their comments; it is not that they necessarily are personally after anything, but they are providing input to you. It is a valuable service to us all. But the WG is still in charge of the operations, or if, there's a serious enough problem, then I will raise a Discuss. In this case, I do agree with the first editorial suggestion of being explicit about the base (even if it is clearer in the ABNF). But it is your job to determine if you think the change is worthwhile and correct. Then there are issues that we might raise that are truly problematic, and some that are potentially problematic. I think the ordering issue could be seen in the latter category (and I have a similar user perspective as Elwyn). But if the WG/chair has a good explanation of the situation (e.g., we've discussed this and the current text is the compromise that was reached), that is often fine. I think so too in this case. Then again I actually read Elwyn's comment in a slightly different light. Calling for clarity on whether there's an agreement on the ordered/unordered nature of the set. Obviously, bits are in a particular order on the wire, but the argument you WG has had is probably on the semantics of what that means; and this is a software issue. Given two same but differently ordered inputs, does the software produce "equivalent" object. Obviously there are multiple ways of implementing this, and I fully understand why the question is non-trivial for the WG. Personally, I would note the lack of universal agreement on this on the document. Maybe worthwhile some discussion on the upcoming IESG telechat… but at the same time I at least am not interested in pushing the WG to *solve* the agreement or even to entertain lengthy debates. Running code trumps other concerns in this case, IMO. Jari On Dec 18, 2013, at 3:04 AM, Paul Hoffman <[email protected]> wrote: > On Dec 17, 2013, at 4:52 PM, Elwyn Davies <[email protected]> wrote: > >> I am coming at it from the perspective of a user. When I was first >> doing things with JSON, I could not find anything that told me either >> that array elements could be anything or that object order didn't >> mattter. > > You noted earlier the issue with "array elements could be anything", and > based on that, we added words to that effect. We cannot say "object order > didn't matter" because it does for some parsers. > >> This wasted time for me and affected the code I was writing. > > Correct. If RFC 4627 had been written more carefully, this would not be a > problem. It wasn't written carefully in a number of areas that affect > interoperability, as we note (as politely as possible) throughout the > document at hand. > > It sounds like you are chafing against the charter, which prohibits us from > making significant changes that will break implementations that made > different guesses about what the sloppy parts of RFC 4627 meant. Jari can > decide if that is significant enough to send the document back to the WG for > this (and at least three other areas) where we were forced to come up with > "if you do X you will most likely be interoperable" wording, and have us make > breaking changes to the new document. I hope that doesn't happen. > >> There are quite a lot of potential users. > > Certainly. And that is the motivator for the wording that we added, instead > of just moving RFC 4627 to standards track with no warning about the > sloppiness. > > --Paul Hoffman _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
