W3C home > Mailing lists > Public > public-rif-wg@w3.org > June 2008

AW: Media-Type (MIME type) for RIF

From: Adrian Paschke <adrian.paschke@biotec.tu-dresden.de>
Date: Sat, 14 Jun 2008 12:56:53 +0200
To: "'Boley, Harold'" <Harold.Boley@nrc-cnrc.gc.ca>, "'Sandro Hawke'" <sandro@w3.org>
Cc: "'RIF WG'" <public-rif-wg@w3.org>
Message-Id: <20080614105641.0D43570000DB@mailserver.biotec.tu-dresden.de>

Excellent idea, a "rif + xml" MIME media type.

We also would need to list the security concerns, e.g. with respect to
external function calls from a RIF rule set, transport of RIF documents via
transport protocols and carrying application specific data in RIF documents
(e.g. wrapped as facts or embedded in constants of type ANY).

Something like this might do:


Security considerations

  Because RIF rules can execute external functions and can carry application

  defined data whose semantics is
  independent from that of any MIME wrapper (or context within which the
  MIME wrapper is used), one should not expect to be able to understand
  the semantics of the RIF document based on the semantics of the MIME
  wrapper alone.  Therefore, whenever using the application/rif+xml
  media type, it is STRONGLY RECOMMENDED that the security implications
  of the context within which the RIF document is used is fully
  understood. The security implications are likely to involve both the
  specific transport of a RIF document with an underlying protocol as well 
  as the application-specific semantics in the target execution environment 
  of the RIF rule sets and the data carried in the RIF document.

  In addition, as this media type uses the "+xml" convention, it shares
  the same security considerations as the XML MIME media type.

- Adrian

-----Ursprüngliche Nachricht-----
Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im
Auftrag von Boley, Harold
Gesendet: Freitag, 13. Juni 2008 21:31
An: Sandro Hawke
Cc: RIF WG
Betreff: RE: Media-Type (MIME type) for RIF


Sandro,

http://www.w3.org/2002/06/registering-mediatype

links to

http://www.ietf.org/rfc/rfc3023.txt

whose sections 8.16-8.18 could act as paradigms.

What about this, where [RIF-BLD] is our LC submission of BLD
(assuming this can later be generalized to [RIF-FLD] with the
full RIF syntax for logic dialects, including the PRD logic):


 Application/rif+xml

   Content-type: application/rif+xml

   <?xml version="1.0" ?>

   RIF documents identified using this MIME type are XML documents whose
   content describes rules, as defined by [RIF-BLD].  As a format based
   on XML, RIF documents SHOULD use the '+xml' suffix convention in
   their MIME content-type identifier.  However, no content type has yet
   been registered for RIF and so this media type should not be used
   until such registration has been completed.


I think you should add a new BLD boilerplate section 9 Appendix: ...
corresponding to the template in rfc4288.txt section 10.
We can then discuss it and I will certainly help filling it out.

-- Harold


-----Original Message-----
From: Sandro Hawke [mailto:sandro@w3.org] 
Sent: June 12, 2008 2:06 PM
To: Boley, Harold
Cc: RIF WG
Subject: Media-Type (MIME type) for RIF


Sorry, but I made a mistake when I said we didn't need to worry about
media-type registration for Last Cast.   The registration form is
supposed to be a normative appendix (to BLD, I think), as per:

   http://www.w3.org/2002/06/registering-mediatype

Harold, do you have time to give that a try?  In particular, the
template in section 10 of http://www.ietf.org/rfc/rfc4288.txt ?

There is some complication here, though, in the media type being for all
of RIF, not just BLD.  That's kind of tricky.....  Ponder, ponder.
Perhaps BLD should just name the expected mime type
("application/rif+xml" I guess) and say the full registration will
follow (in some general RIF-syntax document?).

     -- Sandro

(this completes ACTION-475 woefully late.)
Received on Saturday, 14 June 2008 10:57:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:49 GMT