Hi Sabine and other authors, How are you? Since the last review from Dawn ( https://mailarchive.ietf.org/arch/msg/alto/ZSH5Z1ujBvh4YjQxZLwjPNocXRM/?qid=4922c9c845f02b2bd9c02cc751c74c87), I have not found the draft was updated yet. From the agreement in IETF 99, there are a lot of text harmonization work. I assume the revision is in progress. I just append some technical review for the current version below. Hopefully, it will be helpful.
=== Section 3.1., paragraph 3: > A member "calendar-attributes" MUST appear only once for each > applicable cost type name of a resource entry. If "calendar- > attributes" are specified several times for a same "cost-type-name" > in the capabilities of a resource entry, the ALTO client SHOULD > ignore any calendar capabilities on this "cost-type-name" for this > resource entry. I think it will be much better to adopt the finest granularity than just ignore all, if there are more than one "calendar-attributes" object for the same "cost-type-name". Section 3.1., paragraph 9: > * is the duration of an ALTO calendar time interval, expressed as > a time unit appended to the number of these units. The time > unit, ranges from "second" to "year". The number is encoded > with an integer. Example values are: "5 minute" , "2 hour", > meaning that each calendar value applies on a time interval > that lasts respectively 5 minutes and 2 hours. I prefer to use another field (i.e. "time-interval-unit") to express the time unit and make "time-interval-size" a simple JSONNumber. Because it can simplify the data validation. In this way, the server and client only need to check the data type (number and enumeration) without validating the data content. Section 4.1.1., paragraph 5: > This field MUST NOT be specified if member "calendar-attributes" is > not present for this information resource. From section 8.3.7 of RFC7285, "ALTO implementations MUST ignore unknown fields when processing ALTO messages", I think we need to change "This field MUST NOT be specified" to "This field MUST be ignored". Because if "calendar-attributes" is not present, the server should be a legacy ALTO server which doesn't support calendar extension. So the "calendared" field is an unknown field in the request. Section 4.2.1., paragraph 1: > The extensions to the requests for calendared Endpoint Cost Maps are > the same as for the Filtered Cost Map Service, specified in section > XXXX of this draft. Just a reminder. Don't forget to change "section XXXX". === Once we have an update, I would like to proofread the revision. Chears, Jensen
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
