Hi Adam, Thanks for the clarification. Regarding the situation, I wonder if the following procedure makes sense:
1. Extensions of the ALTO protocol should not explicitly cite a specific (especially the obsoleted) JSON RFC but "follow the same JSON format as in the base protocol (RFC 7285)". 2. Charter a draft to clarify the impacts of new JSON (and probably TLS too) standards on all ALTO-related RFCs. Or maybe we should have a standard paragraph stating the situation and put it in every ALTO extension? What do you think? Best, Kai On Wed, Jan 30, 2019 at 3:30 AM Adam Roach <[email protected]> wrote: > On 1/29/19 12:52 PM, Kai GAO wrote: > > Hi Adam and Benjamin, > > It appears to me that the JSON format is not specific to the cost calendar > but a general problem with all ALTO extensions (or even all protocols > encoded in JSON). > > I wonder if we have some kind of "best practice" in situations like this. > For example, how do other protocols handle this if they originally cited > RFC 7159? > > > I can't offhand think of a protocol in a similar situation regarding JSON. > In other similar cases, the course of action has been somewhat dependent on > the nature of the changes between an older draft and a draft that obsoletes > it. In many cases, changes are backwards-compatible, and I think there's an > implicit assumption that new implementations will automatically make use of > the newer document. > > In other cases where there have been breaking changes, I've seen working > groups issue new clarification documents to "clean up" the discrepancy. For > example, when RFC 6665 replaced RFC 3265, the SIPCORE working group created > RFC 7647 to clarify the impact of those changes on RFC 3515. It wouldn't be > unreasonable for ALTO to do something similar. > > > Since you guys are more senior in the IETF, do you happen to know any RFC > in a similar situation? I think that would be extremely helpful so we don't > have to get into this fight for other on-going ALTO drafts. > > > The decision made by the JSON working group when creating RFC 8259 was > that the practice of trying to deal with multiple encodings was problematic > from an interoperability perspective, and that practical interoperability > is best achieved by always using UTF-8. The RFC itself attempts to capture > this rationale: > > > Previous specifications of JSON have not required the use of UTF-8 > when transmitting JSON text. However, the vast majority of JSON- > based software implementations have chosen to use the UTF-8 encoding, > to the extent that it is the only encoding that achieves > interoperability. > > > A decision by the ALTO working group to intentionally use an obsoleted > version of JSON puts it in the position of reverting consensus established > by the JSON working group. While this kind of consensus revision is > possible in the IETF, it needs to be part of the charter of the working > group that is doing it. Given that ALTO is not chartered to revise JSON > procedures, this isn't allowable. > > If you wanted to normatively cite RFC 8259 and then include non-normative > text indicating that it is possible that older data might be written in > UTF-16 or UTF-32, and that implementations might want a configuration > option that allows reading such formats, I think that would be keeping in > the spirit of the "part of a closed ecosystem" language in RFC 8259. > > /a >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
