Hi James, > On 2 Nov 2021, at 03:03, James Zern <jzern@xxxxxxxxxx> wrote: > > Hi, > > On Sun, Oct 31, 2021 at 5:40 AM Tim Chown via Datatracker > <noreply@xxxxxxxx> wrote: >> >> Reviewer: Tim Chown >> Review result: Has Nits >> >> Hi, >> >> I have reviewed this document as part of the Operational directorate's ongoing >> effort to review all IETF documents being processed by the IESG. These >> comments were written with the intent of improving the operational aspects of >> the IETF drafts. Comments that are not addressed in last call may be included >> in AD reviews during the IESG review. Document editors and WG chairs should >> treat these comments just like any other last call comments. >> >> This draft serves as the IETF standards document through which the WebP image >> format is registered with IANA. >> >> The document is ready for publication with Nits to be addressed. Note I am not >> overly familiar with such registration procedure, but have read through RFC6838 >> since being assigned this draft for review, given 6838 defines the registration >> requirements. >> >> General comments >> >> I think the abstract should say this document provides the WebP media type >> registration with IANA, as required by RFC 6838, not just what WebP is. >> >> The draft includes pointers to the specifications for GIF, JPG and PNG but it >> might be useful to confirm which documents (or additional documents) serve the >> registration function for those formats. >> > > Meaning pointers to registration RFCs like this one if they exist? Yes. It’s not required, and its more perhaps something I’d just be interested to see as this is the first RFC of this type I’ve reviewed. So if you happen to know the things to cite it would be nice, but if not, no worries. >> In RFC6838 section 4.6, the security requirements are detailed (see >> https://datatracker.ietf.org/doc/html/rfc6838#section-4.6). I don’t think >> these have all been addressed in this document. Section 4.6 for example says >> that the draft MUST state whether “active content” is employed or not, and if >> it is, detail steps taken, but I don’t see that here. Similarly it SHOULD >> discuss compression. I’d suggest a quick review of 4.6 for compliance. >> >> I don’t see the IANA registry cited in this document - it is mentioned in >> Section 5 but an explicit pointer would use useful. I believe it’s the one at >> https://www.iana.org/assignments/media-types/media-types.xhtml >> >> I also looked at compliance of this draft in Section 2.1 with Section 6.2 of >> RFC 6838. I think this draft should explicitly include the Full Name and >> suffix used, and while the subtype name listed is also the suffix, perhaps make >> that explicit. > > Does this apply? This isn't registering a suffix, but the media type itself. Again, I’m not familiar with this registration RFC procedure, I’m just looking at Section 6.2 of RFC 6838 which lists Name and +Suffix, so I’d assume that was WebP (is there a full name?) and .webp. But it may not be needed. >> Finally, I see personal email contacts included, though RFC 6838 says “The >> "owner" of a media type registered in the standards tree is assumed to be the >> standards-related organization itself.”, so should there be a more generic >> google contact or owner listed? > > I can make this opensource@xxxxxxxxxx or look for another generic > contact if that helps. I think it may be good for longevity of the contact info to use a more generic contact address, and it would allow multiple people to be reached and potentially respond faster. Best wishes, Tim > >> — >> Tim >> >> >> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
