On Fri, Feb 28, 2020 at 04:26:01PM -0500, Y. Richard Yang wrote: > Dear Jürgen, > > Always excellent comments. Please see below. > > On Fri, Feb 28, 2020 at 1:18 PM Schönwälder, Jürgen < > j.schoenwael...@jacobs-university.de> wrote: > > > 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? > > > > > It indeed can help a lot if we could introduce a new cost mode, but the > change would be > more substantial. > > Looking at your proposal on spelling out "when and how costs of other data > types are > signaled," which is an excellent suggestion. How does the following look: > > "... Therefore the implementor of this extension MUST consider that a cost > entry is an > array of values. Specifically, an implementation of this extension MUST > parse > the "number-of-intervals" attribute of the "calendar-attributes" in an IRD > entry > announcing a service providing Cost Calendar. The implementation then will > know that a cost entry of the service will be an array of values, and the > expected > size of the array is that specified by the "number-of-intervals" attribute. >
So the signal is the "number-of-intervals" attribute, this works for me. I think it helps to spell this out. /js -- 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
