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

[Kai GAO <[e-mail]>]

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 <[e-mail]> 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
>