On Fri, Feb 28, 2020 at 03:00:31PM +0000, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote: > Dear IESG reviewers, Jürgen, Brian, Barry, > > Thank you very much for your review and suggestions. Upon your feedback, we > have posted a new version 18, that hopefully addresses your comments. > Besides, some lower/upper case typo harmonization has been done on > expressions such as "Client", "Server", "cost type". > We look forward to having your feedback, >
Thanks for the changes. All looks good but I am still struggling a bit with the type change of the cost field. Revision -18 has this new text: [...] Therefore the implementor of this extension MUST consider that a cost entry is an array of values. I do not really understand what this MUST tries to achieve or what you expect an implementer to do exactly. RFC 7285 section 11.2.3.6 says: [...] An implementation of the protocol in this document SHOULD assume that the cost is a JSONNumber and fail to parse if it is not, unless the implementation is using an extension to this document that indicates when and how costs of other data types are signaled. It may help to spell out 'when and how costs of other data types are signaled' instead of writing "the implementor [...] MUST consider". If the idea is that the usage of an array is signaled by the usage of an array, then say so, if there is some other way to signal this before I try to parse, then say so as well. We should not rely on implementers to consider and find their own solutions. /js PS: I do not know much about ALTO but out of curiosity: has it been considered to allocate new "cost-mode" values "numerical*" and "ordinal*" that signal that the cost field is a vector of numerical/ordinal values and not just a scalar? -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto