RE: media type (mime type) registration (ACTION-536)

I think this basically is what we need at this point, given that
we need to bring up Security considerations for dialects beyond
BLD already now.

It would be non-trivial to strive for 'completeness' of possible
security risks. E.g., while we now have (for non-cyclic imports?)

            Through the use of "import", it may also require
          arbitrary URI dereferencing, which may consume all available
          network resources on the consuming system or other systems.

we don't have something about RIF documents encoding a busy beaver
(http://en.wikipedia.org/wiki/Busy_beaver) or being non-terminating,
which can be obvious in special cases, e.g. via a rule p() :- p(),
but which is undecidable in general.

My suggestions below are only stylistic, and I'd be fine with a
BLD freeze still today for LC purposes
(cf.
http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0046.html),
but I don't know if Michael would be, and Adrian P can hardly
respond today because of the timezone difference.

So, also given the importance of Security considerations, maybe
we should postpone freezing till Monday to avoid a double freeze.

BLD Reviewers can of course already read the spec over the weekend
on the wiki, and point out issues there:
http://www.w3.org/2005/rules/wiki/BLD

-- Harold


          Full and complete processing of a RIF document, even one
          conforming to BLD, may require unlimited CPU and memory
          resources.
-the term 'dialect' should be introduced->
          Full and complete processing of a RIF document, even one
          conforming to the RIF-BLD dialect, may require unlimited CPU
and memory
          resources.


          RIF is a relatively complicated 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.
-->
          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.


          Because RIF may be extended with local, application defined
          data types and functions, arbitrary vulnerabilities may be
          introducted.
-->
          Because RIF may be extended with local, application defined
          data types and functions, arbitrary vulnerabilities may be
          introduced.


       This media type is intended to be shared with other RIF
       dialects (profiles), to be specified in the future.
       Interoperation between the dialects is governed by the RIF
       specifications.
-'profile' has another, technical meaning in the specs->
       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.

       This media type is intended to be shared with other RIF
       dialects (profiles), to be specified in the future.
-'profile' has another, technical meaning in the specs->
       This media type is intended to be shared with other RIF
       dialects, to be specified in the future.

Note short-distance-repetition of sentence.


           As with XML in general (See RFC 3023 (XML Media Types)),
           there is magic number for this format.
-?->
           As with XML in general (See RFC 3023 (XML Media Types)),
           there is no magic number for this format.


             It may theoretically
           be missing if the document use XML entities in an
           obfuscatory manner.
-->
             It may theoretically
           be missing if the document uses XML entities in an
           obfuscatory manner.


-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Sandro Hawke
Sent: July 4, 2008 6:04 PM
To: public-rif-wg@w3.org
Subject: media type (mime type) registration (ACTION-536)



I've drafted text for BLD:

http://www.w3.org/2005/rules/wiki/BLD#Appendix:_RIF_Media_Type_Registrat
ion

Please review/comment asap.

Adrian, I couldn't quite follow all that you were saying in your draft
of the security section; if I missed some important aspect, please let
me know.

The process involves a comment period from the ietf-types mailing list,
which I have now subscribed to.   Presumably we'll get some feedback
from them....

    -- Sandro

Received on Friday, 4 July 2008 23:28:11 UTC