Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

[Adam Roach <[e-mail]>]

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