Hi. That seems to be a reasonable outcome... sorry it took a while to get there and thanks for your forbearance.
Regards, Elwyn On Thu, 2013-12-19 at 18:17 +0200, Jari Arkko wrote: > I would be very happy with this. And again, I only wanted to briefly discuss > this, so I don't want to hold the document even if you do not add something. > But I like the addition, and it also seems to match my understanding of the > real situation. > > Jari > > On Dec 19, 2013, at 6:16 PM, Tim Bray <[email protected]> wrote: > > > Or to be more in tune with the language in the rest of the spec. “JSON > > parsing library implementations have been observed to differ as to whether > > or not they make information as to the ordering of object members > > available; therefore, implementations whose behavior does not depend on > > object ordering will be interoperable in the sense that they will not be > > affected by these differences.” > > > > > > On Thu, Dec 19, 2013 at 8:08 AM, Tim Bray <[email protected]> wrote: > > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
