- From: Philippe Le Hegaret <plh@w3.org>
- Date: Tue, 26 Jan 2021 17:20:37 -0500
- To: public-rif-dev@w3.org
Posting this here in case it attracts more attention. Philippe -------- Forwarded Message -------- Subject: Fyi: [IANA #1186601] Request for media type application/rif+xml Date: Tue, 19 Jan 2021 09:17:23 -0500 From: Philippe Le Hegaret <plh@w3.org> Organization: World Wide Web Consortium To: public-rif-comments@w3.org CC: Sandro Hawke <sandro@w3.org> Sandro noted that we never registered the media type for RIF, so I submitted a request 2 weeks ago and received the following feedback. I believe the next step would be to produce a revision of the REC that includes the feedback. Unless I'm mistaken, we should be able to do so through editorial changes: https://www.w3.org/2020/Process-20200915/#revised-rec-editorial I included for reference the template that I submitted at the end. Is there anyone interested in working with me to help answer questions and provide a revision? Philippe ======== IETF review ============================= 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. ============== end of IETF review ============== ==== registration template =============== On Wed Jan 06 19:15:51 2021, plh@w3.org wrote: > > 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) > > Encoding considerations: 8bit > same as RFC 3023 (XML Media Types) > > 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. > > 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). > > 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 > > > Applications which use this media: > same as RFC 3023 (XML Media Types) > > > > 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 Tuesday, 26 January 2021 22:20:41 UTC