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
