We could a one-sentence paragraph to the end of 4: “Implementations also differ as to whether or not they make the order of object members available to receiving software.”
On Thu, Dec 19, 2013 at 6:02 AM, Jari Arkko <[email protected]> wrote: > 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
