Request preliminary check of 8 personal media types

[Damian Dollahite]

Mark Baker wrote:
> The general approach looks fine, but there's less information there
> than would typically be available in the registration template.
>

What's missing, specifically? Should the registrations duplicate the 
format specifications instead of simply providing a URI for the longer 
documents?

> The use of "version" parameters is often problematic though;
> historically, those kinds of parameters aren't used.  Do the different
> versions of the Z machine have, say, different magic numbers or are
> otherwise distinguishable?  Can you provide any version to a typical
> processor and it will just work?  If not, you might consider separate
> media types.
>

Most processors can handle versions 3, 5, 7, and 8. Support for the 
other versions is spottier, because actual examples of them are very 
rare, and version 6 has special features that many processors don't want 
to implement. I'm well aware that version parameters aren't often used 
in practice, and I don't expect this one to be, but I think it's useful 
to have it available.

> The use of "t3vm" as a separate facet in the personal tree is
> unconventional, and might be better suited to the vendor tree.  Minor
> issue though IMO, since AFAIK, there's no semantic difference between
> them.
>
>

RFC 4288 says:

   "Registrations in the vendor tree will be distinguished by the leading
   facet "vnd.".  That may be followed, at the discretion of the
   registrant, by either a media subtype name from a well-known producer
   (e.g., "vnd.mudpie") or by an IANA-approved designation of the
   producer's name that is followed by a media type or product
   designation (e.g., vnd.bigcompany.funnypictures)."


I don't know what would be involved with getting "t3vm" IANA-approved as 
a product designation, but somehow I think it would be more trouble than 
it would be worth. RFC 4288 also says that the vnd. tree is for 
"commercially available products." It doesn't define exactly what a 
"commercially available product" is, but whatever the definition I doubt 
TADS 3 qualifies. As you say, there doesn't seem to be much, if any, 
semantic difference between vnd. and prs., only eligibility 
requirements. The fact that the prs. tree is for "products that are not 
distributed commercially" seems to imply that the same syntax rules 
apply as for vnd.

M.D. Dollahite

>
> On 5/3/06, Damian Dollahite <master.ryukage at gmail.com> wrote:
>> I would like to request a preliminary check of 8 media types collected
>> in this document:
>>
>> http://purl.org/int-fiction/ifmi/documents/mediatypes/
>>
>> This document is not a registration form or specification, rather it is
>> a discussion of issues that need to be addressed so that these formats
>> can be registered.  It does include examples of how the registration
>> forms might be filled out, however.
>>
>> Currently, these file formats are being transferred using "x-" prefixed
>> types; I'm fairly certain that none of the controllers are aware that
>> the prs. tree is open to everyone, or else they just assume that
>> registration will involve too much paperwork to bother with.  I plan to
>> contact them and present them with this document, as well as
>> volunteering to handle the paperwork for them.
>>
>> Once I've discussed these types with the format controllers, I'll submit
>> them for another review before proceeding with registration; at this
>> point all I need is a quick look-over to make sure I won't be giving the
>> format controllers bad advice.  The thing that especially concerns me is
>> my use of a "+blorb" suffix on some of the types.  I realize "+"
>> suffixes are discouraged, but something of that nature is needed to
>> allow correct dispatch of Blorb files.  If "+blorb" is simply not
>> appropriate, I'd appreciate suggestions on how else to solve the
>> problem; I do not believe a "." or "-" facet is semantically correct 
>> here.
>>
>> Thank you,
>>
>>     M.D. Dollahite
>>
>>
>>
>>
>


-- 
M. Damian Dollahite

-------------- next part --------------
A non-text attachment was scrubbed...
Name: master.ryukage.vcf
Type: text/x-vcard
Size: 134 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20060924/1c86e823/master.ryukage.vcf