DR-09-0034 (was "Re: DR-09-0032 and DR-09-0034")

[MURATA Makoto (FAMILY Given)]

Caroline,

> I would be inclined to consult the ODF registrations
> for an indication of what might be appropriate.  OASIS has registered a
> series of media types with the shared prefix 'vnd.oasis.opendocument'
> and I would be inclined to take the same approach for OOXML.  There does
> seem to be the question of what organization the registration should
> come from (SC34, ECMA, ??).

In the case of RELAX NG compact syntax, I used the standard tree rather
than the vendor tree.  Note that SC34 can use the standard tree if some
standard or amendment explains the media type to be registered.

We can now do the same thing for OOXML media types, but I am inclined
to continue to use media type names as shown in 29500.  Since the
maintainer of OOXML is now SC34/WG4, I believe that SC34/WG4 is now the
"vendor" for OOXML.

> Note the security considerations.  I imagine something similar (mentioning 
> the possibility of macros being embedded, privacy, etc.) would be
> needed for OOXML.  

Security considerations are required.  RFC 3023 already explains them,
but we might want to add more.  Which of the currently use media 
types (see R-09-0034) contains scripts or programs?

By the way, if my understanding is correct, there are no media types
for OOXML documents.  Although we have media types for logical parts of
OOXML documents, there are no media types for OOXML documents as a
whole.   (Note: application/pdf exists.)

I believe that we are obliged to create and register a media type for
OOXML documents.  (I will submit another defect report.)

I wrote:
> By the way, 
> when the pack URI scheme is used to reference to files within OOXML 
> zip files, will our media types be returned?

Having read Part 2, I guess URIs using the pack scheme are required to
return the content type as specified in [Content_Types].xml.  
Since this is not clearly specified in Annex B of Part 2, we should 
probably introduce "B.5 Media types" and explicitly state this
requirement.  (I will submit yet another defect report.)


Cheers,
-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT at asahi-net.or.jp>