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

[Vijay Gurbani <[e-mail]>]

Well, procedurally speaking, if we want to fix the root cause (RFC 7285), I
suspect that we can do so through a RFC that modifies RFC 7285.  Related
questions like how quick can we do that, is it in our charter and if not
how to proceed, etc. are questions that can be attended to once the WG
decides that modifying RFC 7285 would be the best course of action.

Do I get the sense that the WG thinks that this is the best course of
action?  (I must apologize as I am coming up to speed on this issue.  If I
was to produce a 1 sentence summary of the issue here, it is that RFC 8259
normatively requires UTF-8 encoding and that there are existing ALTO
implementations conformant to RFC 7285 that use encodings other than
UTF-8.  Is that accurate?).

Thanks,

- vijay

On Wed, Jan 30, 2019 at 3:29 PM Kai GAO <[e-mail]> wrote:

>
> Hi Benjamin,
>
> Thanks for the reply.
>
> DISCLAIMER: I'm only speaking on behalf of myself.
>
> Well, the situation is that we don't know the answer to the key question
> at the moment and probably also in the near future.
> Thus, the problem at hand is "how do we proceed if we don't know the
> answer".
> My personal opinion is that ALTO should be self-contained so the principle
> is that extensions should not conflict with the base protocol.
> So instead of patching every draft, why don't we just patch the root cause
> (RFC 7285)?
>
> However, I don't really know if this is the best practice in IETF.
> Since you and Adam are the experts here, we would like very much to
> leverage your expertise a bit and hear your opinions on this procedural
> problem.
> (I imagine the implication is that we should not proceed until we find out
> the answer?)
>
> Back to the encoding. If UTF-8 is the de facto JSON encoding in JSON
> libraries, as Adam pointed out, I don't see why it would not be for ALTO
> usage.
> I don't truly believe there would be a nontrivial amount of developers who
> use an 18-century JSON library or reinvent the wheel just to be
> interoperable with ALTO.
>
> Just my 2 cents.
>
> Best,
> Kai
>
>
>
>
> On Thu, Jan 31, 2019 at 12:13 AM Benjamin Kaduk <[e-mail]> wrote:
>
>> On Wed, Jan 30, 2019 at 12:44:43PM +0800, Kai GAO wrote:
>> > 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?
>>
>> This seems to be sidestepping the key question, of whether UTF-8 is
>> actually the de facto interoperable JSON encoding for ALTO usage, or
>> whether there is nontrivial usage of other encodings.  It seems a little
>> odd to consider procedural options without knowing what the right answer
>> is.
>>
>> -Benjamin
>>
>