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
