Hi Vijay,
Thanks for the clarification. I will then just cite RFC 8259 in the intro and
3.1. Maybe the “operational considerations” section can include a paragraph
saying that implementations using UTF-{16,32} need to be cognizant of both the
8259 evolution that mandates UTF-8, essentially for interoperability reasons.
Therefore it is recommended for them to switch to UTF-8 encoding.
Thanks,
Sabine
From: Vijay Gurbani <[email protected]>
Sent: Tuesday, February 05, 2019 7:31 PM
To: [email protected]; Randriamasy, Sabine (Nokia -
FR/Paris-Saclay) <[email protected]>
Cc: [email protected]
Subject: Status of cost-calendar
Sabine, Based on my posting on the mailing list [1], it does not appear that
ALTO or any of its extensions are intimately tied to UTF-{16,32}.
As such, please reference the new JSON RFC 8259 in the Introduction to the
cost-calendar draft and please move it ahead as soon as possible after
incorporating other comments from IESG review.
I have forgotten whether we have to redo the WG and IETF last calls. Can you
please provide the status of the draft with respect to IETF last call and
whether we need to do a WGLC again.
[1] https://mailarchive.ietf.org/arch/msg/alto/EGuPfDqoYBv7H8grPXE0qtjQsGc
Thank you.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
