- From: Philippe Le Hegaret <plh@w3.org>
- Date: Fri, 26 Feb 2021 15:43:18 -0500
- To: iana-mime@iana.org
- Cc: Ralph Swick <swick@w3.org>, www-archive@w3.org
Hi Amanda, Thank you for the suggestions from the reviewer. They're all good suggestions. Unfortunately, it turns out that the interest in updating the existing W3C Recommendation isn't there. At this time, we'd like to withdraw our registration request for this media type. If the interest changes, we will revise the W3C Recommendation before re-applying for registration. Thank you, Philippe On 2/17/2021 5:58 PM, Amanda Baber via RT wrote: > Hi Philippe, > > Let me know if you need anything else from the reviewers. > > Best regards, > > Amanda Baber > Lead IANA Services Specialist > > On Tue Jan 26 18:51:44 2021, plh@w3.org wrote: >> I transmitted the feedback along and I am now waiting for answers on >> our >> side. >> >> Thank you, >> >> Philippe >> >> On 1/26/2021 12:58 AM, Amanda Baber via RT wrote: >>> Dear Philippe, >>> >>> I'm sending a weekly reminder for the request below. Please let us >>> know if you have any questions that need to be answered by the >>> reviewer before a revision can be completed. >>> >>> Best regards, >>> >>> Amanda Baber >>> Lead IANA Services Specialist >>> >>> On Tue Jan 19 00:36:34 2021, michelle.cotton wrote: >>>> Dear Philippe, >>>> >>>> The media types expert has reviewed your request. He has indicated >>>> the following: >>>> >>>> Various issues, but really nice security considerations. >>>> >>>> Please provide a revised template to address his questions/feedback. >>>> >>>> Thank you, >>>> >>>> Michelle Cotton >>>> Protocol Parameters Engagement Sr. Manager >>>> IANA Services >>>> >>>> >>>> >>>>> ===== >>>> >>>> First and foremost, this registration refers to RFC 3023 throughout. >>>> RFC 3023 >>>> is obsolete; the current XML registration specification is RFC 7303. >>>> All of >>>> the references need to be updated accordingly. >>>> >>>>> Name: Philippe Le Hegaret >>>>> Email: plh@w3.org >>>> >>>>> Media type name: application >>>>> Media subtype name: rif+xml >>>> >>>>> Required parameters: none >>>> >>>>> Optional parameters: >>>>> charset, as per RFC 3023 (XML Media Types) >>>> >>>> This should reference section 3 of RFC 7303 specifically. Please >>>> also >>>> take note >>>> of the guidance in section 4.2, in particular that if this media >>>> type >>>> doesn't >>>> need a charset parameters it's best not to define one. >>>> >>>>> Encoding considerations: 8bit >>>>> same as RFC 3023 (XML Media Types) >>>> >>>> This implies that charsets such as UTF-16 variants are never used. >>>> Are >>>> you sure this is what you want? I don't see any charset restrictions >>>> in >>>> the specification. >>>> >>>>> Security considerations: >>>> >>>>> Systems which consume RIF documents are potentially vulnerable >>>>> to attack by malicious producers of RIF documents. The >>>>> vulnerabilities and forms of attack are similar to those of >>>>> other Web-based formats with programming or scripting >>>>> capabilities, such as HTML with embedded Javascript. >>>> >>>>> Excessive Resource Use / Denial of Service Attacks >>>> >>>>> Complete processing of a RIF document, even a conformant >>>>> RIF Core document, may require arbitrarily great CPU and >>>>> memory resources. Through the use of "import", processing >>>>> may also require arbitrary URI dereferencing, which may >>>>> consume all available network resources on the consuming >>>>> system or other systems. RIF consuming systems SHOULD >>>>> implement reasonable defenses against these attacks. >>>> >>>> The use of capitalized words like "SHOULD" has no assigned meaning >>>> in media type registrations; please use "should" instead. >>>> >>>>> Exploiting Implementation Flaws >>>> >>>>> RIF is a relatively complex format, and rule engines can be >>>>> extremely sophisticated, so it is likely that some RIF >>>>> consuming systems will have bugs which allow specially >>>>> constructed RIF documents to perform inappropriate >>>>> operations. We urge RIF implementors to make systems which >>>>> carefully anticipate and handle all possible inputs, >>>>> including those which present syntactic or semantic errors. >>>> >>>>> External (Application) Functions >>>> >>>>> Because RIF may be extended with local, application defined >>>>> datatypes and functions, new vulnerabilities may be >>>>> introduced. Before being installed on systems which consume >>>>> untrusted RIF documents, these external functions should be >>>>> closely reviewed for their own vulnerabilities and for the >>>>> vulnerabilities that may occur when they are used in >>>>> unexpected combinations, like "cross-site scripting" >>>>> attacks. >>>> >>>>> In addition, as this media type uses the "+xml" convention, it >>>>> shares the same security considerations as other XML formats; >>>>> see RFC 3023 (XML Media Types). >>>> >>>> These security considerations are very well done. The only thing >>>> that >>>> needs to be added is some mention of integrity and confidentiality >>>> protections. Simply saying that such protections may be needed and >>>> if so can be provided externally would be sufficient. >>>> >>>>> Interoperability considerations: >>>> >>>>> This media type is intended to be shared with other RIF >>>>> dialects, to be specified in the future. Interoperation >>>>> between the dialects is governed by the RIF specifications. >>>> >>>>> Published specification: >>>> >>>>> https://www.w3.org/TR/2013/REC-rif-core- >>>>> 20130205/#Appendix:_RIF_Media_Type_Registration >>>> >>>> Pointing at the registration template within the specification isn't >>>> what's needed here, nor is it what appears in the registration form >>>> within the specification itself: >>>> >>>> RIF Core Dialect >>>> W3C Working Draft (Recommendation Track) >>>> http://www.w3.org/TR/rif-core/ >>>> >>>> RIF Datatypes and Builtins >>>> W3C Working Draft (Recommendation Track) >>>> http://www.w3.org/TR/rif-dtb/ >>>> >>>> RIF Basic Logic Dialect >>>> W3C Working Draft (Recommendation Track) >>>> http://www.w3.org/TR/rif-bld/ >>>> >>>> RIF Production Rule Dialect >>>> W3C Working Draft (Recommendation Track) >>>> http://www.w3.org/TR/rif-prd/ >>>> >>>> RIF Framework for Logic Dialects >>>> W3C Working Draft (Recommendation Track) >>>> http://www.w3.org/TR/rif-fld/ >>>> >>>> This media type is intended for use by all RIF dialects, >>>> including those to be specified in the future. Identification >>>> of the RIF dialect in use by a document is done by examining >>>> the use of specific XML elements within the document. >>>> >>>> >>>>> Applications which use this media: >>>>> same as RFC 3023 (XML Media Types) >>>> >>>> This doesn't really make sense, and once again what's in the >>>> specification is better: >>>> >>>> See: http://www.w3.org/2005/rules/wiki/Implementations >>>> >>>>> Fragment identifier considerations: >>>> >>>>> same as RFC 3023 (XML Media Types) >>>> >>>>> Restrictions on usage: >>>>> None >>>> >>>>> Provisional registration? (standards tree only): >>>>> (none) >>>> >>>>> Additional information: >>>> >>>>> 1. Deprecated alias names for this type: (none) >>>>> 2. Magic number(s): same as RFC 3023 (XML Media Types) >>>>> 3. File extension(s): .rif (or .xml) >>>>> 4. Macintosh file type code: TEXT >>>>> 5. Object Identifiers: (none) >>>> >>>>> General Comments: >>>> >>>>> Person to contact for further information: >>>> >>>>> 1. Name: Sandro Hawke >>>>> 2. Email: sandro@w3.org >>>> >>>>> Intended usage: Common >>>>> (empty) >>>> >>>>> Author/Change controller: RIF is a product of the Rule Interchange >>>>> Format (RIF) Working >>>>> Group of the World Wide Web Consortium (W3C). See >>>>> http://www.w3.org/2005/rules/wg for information on the group. >>>>> The W3C (currently acting through this working group) has >>>>> change control over the RIF specification. >>> >
Received on Friday, 26 February 2021 20:43:22 UTC