Hi Dale, > On 6 May 2014, at 19:53, [email protected] (Dale R. Worley) wrote: > > 2014-04-28 14:59 GMT+02:00 Alexey Melnikov <[email protected]>: >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-salud-alert-info-urns-12.txt >> Reviewer: Alexey Melnikov >> Review Date: 27 April 2014 >> IETF LC End Date: 25 April 2014 >> IESG Telechat date: (if known) N/A >> >> Summary: Ready with nits/questions. >> >> >> Major issues: >> None >> >> Minor issues: >> >> 13. User Agent Behaviour >> >> The User Agent (UA) MUST produce a reasonable rendering regardless of >> the combination of URIs (of any schemes) in the Alert-Info header >> field. >> >> This MUST is not well defined to be implementable. How can conformance or >> violation of this requirement can be tested? I suggest you avoid using RFC >> 2119 language here. > > The authors agree and will change the MUST to "must". > > Because we had another comment regarding this paragraph from our Area > Director (Richard Barnes), we will add following text at the end of > that paragraph: > > In particular, unless the containing message is a request and is > immediately rejected, the UA SHOULD provide some alert unless it is > explicitly instructed not to (for example, by Alert-Info URIs that > it understands, the presence of a Replaces or Joins header field, > local policy, or direction of the user).
I think the additional text is good. >> Has this been submitted to the [email protected] mailing list for 2 >> weeks review? (as per RFC 3406) > > The urn-nid review started 3 Oct 2013: > http://www.ietf.org/mail-archive/web/urn-nid/current/msg01218.html > There were no comments. Ok. >> Nits/editorial comments: >> >> "REQ-4: has been deleted. To avoid confusion, the number will not be >> reused". >> >> I find this to be rather unusual. Are these requirements used in RFPs? > > We did not want a renumbering of the requirements in order to avoid > confusion when people sent comments on the requirements. It makes > sense to renumber the requirements now, and we will do so. Thank you. >> In Section 7: >> >> date = [CC] YY [ "-" MM ["-" DD] ] >> >> >> Is there a need for having 2 octet years? Are you trying to save some >> bytes here at the expense of extra (albeit minor) complexity? > > We believe it is valuable to allow just YY, but are willing remove it if > necessary to pass the gen-art review. > > Overall, we have strived to allow brevity in the date formats. > Allowing CC to be optional changes the number of permitted date > formats from 4 (including complete absence) to 7, but it only > increases the number of distinct choices in code that processes dates > from 3 to 4. Given that CC can only be "20" for the next 86 years, > and the general desirability of brevity, we think that it is as > reasonable to make CC optional as it is to make MM and DD optional. Ok. I don't really insist on this change, as long as you thought about this or if both are already implemented. > Dale [for the authors of draft-ietf-salud-alert-info-urns] _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
