Attached find a personal/vanity media type that I just
requested; basically, it puts a URI-based hook in the IANA registry.
It's a thought I had on issue 9
http://www.w3.org/2001/tag/issues.html?type=1#uriMediaType-9
while thiking about comments on on examples in the SPARQL spec
Hoehrmann objects to the use of an unregistered media type for N3
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Jan/0161.html
... which TimBL requested a while back.
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Jan/0007.html
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Forwarded message 1
Name : Dan Connolly
Email : connolly@w3.org
MIME media type name : Application
MIME subtype name : Personal Tree - prs.connolly.t9
Required parameters : format -- an IRI reference to a specification of (or at least: description of) a data format, much like an Internet Media Type specification except that archiving and endorsing the specification is left to the community at large.
Optional parameters :
These parameters allow a sender to provide integrity-constraints on the link to the format specification:
last-modified -- a date in YYYY-MM-DD format that indicates the last modification date of the format specification that the sender is aware of; any format specification modified after this date is to be used at the risk of the consumer
max-age -- a decimal numeral indicating the number of seconds between obtaining an authentic representation of the format and consuming this body (as per HTTP caching RFC2616 section 14.9.3). Consuming this body with an out-of-date format specification is done at the risk of the consumer.
sha1sum -- a hexadecimal numeral that gives a 160bit checksum of the format specification that the sender is aware of; any format specification that does not match the checksum is to be used at the risk of the consumer
key -- a public key (in SECSH Public Key File Format) with which the format specification has been signed; any format specification for which the consumer cannot find a signature by this key is to be used at the risk of the consumer
key-fingerprint -- a fingerprint of a public key as above. hex encoded. colons optional.
Encoding considerations : binary
This media type may require encoding on transports not capable of handling binary.
Security considerations :
The security considerations relevant to any particular body part using this Internet Media Type are those relevant to the format specification identified in the format paremeter. Obtaining an authentic representation of the format specification is also subject to risks associated with dereferencing URIs, especially DNS and HTTP related attacks.
Interoperability considerations :
Some formats will naturally enjoy more popularity and hence wider interoperability than others. Producers are encouraged to re-use widely deployed formats, and consumers are encouraged to evaluate formats using the same mechanisms they would use to evaluate the quality of Web resources in general: incoming links, reviews, etc.
Published specification :
The specification of this format is published in the Web, indirectly via the format parameter.
Applications which use this media :
none at the time of this writing
Additional information :
1. Magic number(s) : none
2. File extension(s) : none
3. Macintosh file type code : none
4. Object Identifiers: none
Person to contact for further information :
1. Name : Dan Connolly
2. Email : connolly@w3.org
Intended usage : Limited Use
This media type is primarily an experimental exploration of the relationship between URIs and media type names, though it is intended to be suitable for use in examples in the SPARQL protocol specification ( http://www.w3.org/TR/rdf-sparql-protocol/ ) . See also
http://www.w3.org/2001/tag/issues#uriMediaType-9
Author/Change controller : Dan Connolly