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

I think we are on the "safe" side with the three paragraphs about potential security problems and the general text about Web languages with programming capabilities.

-Adrian

 
-------- Original-Nachricht --------
> Datum: Fri, 4 Jul 2008 19:27:29 -0400
> Von: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>
> An: "Sandro Hawke" <sandro@w3.org>, public-rif-wg@w3.org
> Betreff: 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
> 
> 

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Received on Saturday, 5 July 2008 06:56:56 UTC