On Sat, Feb 29, 2020 at 3:21 AM Schönwälder, Jürgen < j.schoenwael...@jacobs-university.de> wrote:
> 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. > Yes. Exactly. Thanks a lot for the help! Richard > /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/> > -- Richard
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
