Hi James, That all sounds fine, many thanks. Tim > On 7 Nov 2021, at 03:10, James Zern <jzern@xxxxxxxxxx> wrote: > > 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
