Hi Tim, On Tue, Nov 2, 2021 at 9:07 AM Tim Chown <Tim.Chown@xxxxxxxxxx> wrote: > > 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. > >> Good point. That wasn't revisited as the document evolved. Done locally. > >> 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. > A search on datatracker didn't turn them up [1][2]. IANA [3] lists RFC2045 [4] & RFC2046 [5] for gif/jpeg. They are mentioned in 2046 [6]. PNG points to a PNG author (note personal emails abound). > >> 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 > >> Done locally. > >> 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?) WebP was an extension of WebM where M and P are media and picture respectively, but in practice WebP / WebM are used as the canonical terms. > 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. > We do have TIFF [7] as an (older) example and AVIF has both something to aomedia and a direct contact. WebP is technically a part of the WebM project. We have webmaster@xxxxxxxxxxxxxxx there; I added this locally. [1] https://datatracker.ietf.org/doc/search?name=Media+Type+Registration&sort=&rfcs=on&by=group&group= [2] https://datatracker.ietf.org/doc/search?name=MIME+Type+Registration&sort=&rfcs=on&by=group&group= [3] https://www.iana.org/assignments/media-types/media-types.xhtml [4] https://www.rfc-editor.org/rfc/rfc2045.html [5] https://www.rfc-editor.org/rfc/rfc2046.html [6] https://www.rfc-editor.org/rfc/rfc2046.html#section-3 (2) image -- image data. "Image" requires a display device (such as a graphical display, a graphics printer, or a FAX machine) to view the information. An initial subtype is defined for the widely-used image format JPEG. . subtypes are defined for two widely-used image formats, jpeg and gif. [7] https://www.rfc-editor.org/rfc/rfc3302.html > Best wishes, > Tim > > > > >> — > >> Tim > >> > >> > >> > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
