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

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

Yes, see below, but then Michael's "one thing we forgot" came up,
so to my mind we can either freeze now and consider the dialect
attribute during the WG-internal review, or see if we can agree
on such an attribute by, say, Monday or the Tuesday telecon and
then freeze a version which is closer to what we want to publish.

-- Harold


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

All,

We think BLD is now ready to be frozen, except for the mime type
appendix,
which need to be drafted, discussed and added to all LC documents.

. . .

Harold, Michael
http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0046.html


-----Original Message-----
From: Sandro Hawke [mailto:sandro@w3.org] 
Sent: July 5, 2008 10:16 AM
To: Boley, Harold
Cc: public-rif-wg@w3.org
Subject: 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 15:34:18 UTC