Hi Adam and Benjamin,
Regarding the citation of RFC 8259, in the Introduction, using the JSON format
as specified in RFC 8259 may actually cause backwards compatibility issues with
RFC7285 that uses the JSON format specified in RFC7159. Would it be OK to cite
7159 in the Introduction and add the paragraph below in section 2.2.2
“Compatibility with legacy ALTO Clients" ?
Thanks,
Sabine
<t>Last, for backwards compatibility with <xref target="RFC7285"/>,
this extension encodes its requests and responses using the JSON
Data Interchange Format specified in <xref target="RFC7159"/>.
The latter has been obsoleted by <xref target="RFC8259"/>,
that among others makes UTF-8 mandatory for text encoding to
improve interoperability. Therefore, Clients and Servers supporting
ALTO Calendars SHOULD use UTF-8 for text encoding while still being
able to
successfully read texts in other encodings such as UTF-16 and
UTF-32.</t>
-----Original Message-----
From: Adam Roach <[email protected]>
Sent: Friday, January 25, 2019 10:25 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
<[email protected]>; The IESG <[email protected]>
Cc: [email protected]; Gurbani, Vijay (Nokia -
US/Naperville) <[email protected]>; [email protected];
[email protected]
Subject: Re: Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09:
(with COMMENT)
On 1/25/19 10:06 AM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
> [[SR]] The purpose is actually to lighten the reading. Would the following
> addition to paragraph 3 of section 4.1.3 be OK ?
> "The Server returns Calendars with arrays of 12 numbers. To lighten the text,
> the arrays in the provided example are symbolized by expression "[v1,v2, ...
> v12]" that is otherwise not valid in JSON. The same type of symbolization is
> used in the example Server responses."
That seems a reasonable approach. Thanks!
/a
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
