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.

Good   :-)

> 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.

I thought I pretty-much covered that in "Excessive Resource Use"...

> 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.

Did I miss a message from you that, other than this, you were ready for
a BLD freeze?

I guess I'll try to do one today.....

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

Given Adrian's message (and your edits below, which I did), I think
we're in good enough shape.   I'm sure the IETF reviewers will give us
some changes, too, but we can do that after Last Call.

> 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.

This is the one I didn't address.   It seems like the information needs
to be in both places, and just repeating the sentence seems marginally
better than rephrasing it or pointing to the other section.

      -- Sandro


> 
> 
>            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 Saturday, 5 July 2008 13:17:30 UTC