headers
Mark Baker | 5 Jul 2005 18:22
Picon
Favicon
Gravatar

Re: Old application/atom+xml issues


On Tue, Jul 05, 2005 at 10:33:00AM -0400, Robert Sayre wrote:
> On 7/5/05, Mark Baker <distobj@...> wrote:
> > 
> > I wanted to point out that comments I've made on the
> > application/atom+xml media type registration template have not yet been
> > incorporated into the syntax draft, nor have I received any feedback
> > about why they needn't be.
> 
> See comments from Tim here:
> http://www.imc.org/atom-syntax/mail-archive/msg14423.html
> 
> Sorry you didn't get direct feedback. :/

Ah, I should have thought to check the archives, thanks.

It should have gone to ietf-types though, since that's where public
review of media type registrations happen and where my comments were
sent.  I've CCd ietf-types on this message.

Tim writes;
> He's got a point on the namespace being mentioned, which creates some
> semi-circular dependencies, sigh. As to whether it's currently in use,
> largely due to lobbying from us, recent releases of both Apache and
> IIS tie the application/atom+xml media type to the .atom extension, so
> if people are creating 0.3 files and calling them whatever.atom, this
> could be right. Having said that, I think we should push back. Because
> any such current usage is unlicensed by any spec, & because we plan to
> aggressively deprecate Atom 0.3 once we get 1.0 out and since I
> suspect that 90% of 0.3 feeds come from one place we should have some
(Continue reading)

Permalink | Reply | 16 comments |
headers
Allison Mankin | 5 Jul 2005 20:48

Transport Area requests Media Type review for 3GPP2 MIME registrations


The Transport Area requests a Media Type review
for the registrations in draft-garudadri-avt-3gpp2-mime-02.txt,
intended for the standards tree.

The draft is submitted for Proposed Standard.

One change is known:
  The reference to [bucket] will be updated to
  draft-gellens-mime-bucket-04.txt, which is now on the
  RFC Editor Queue.

Please provide any comments as soon as possible, and
before July 20, 2005.

Thanks,

Allison
Transport Area Director
Permalink | Reply | 0 comments |
headers
Allison Mankin | 5 Jul 2005 20:48

Transport Area requests Media Type review for MPEG4 registration draft


The Transport Area requests a Media Type review for 
for the registrations draft-lim-mpeg4-mime-03.txt, 
intended for the standards tree.

The draft is submitted for Proposed Standard.

Please provide any comments as soon as possible, and
before July 20, 2005.

Thanks,

Allison
Transport Area Director
Permalink | Reply | 0 comments |
headers
Bill de hÓra | 11 Jul 2005 10:08
Favicon
Gravatar

Re: Old application/atom+xml issues


Mark Baker wrote:

> IMO, it matters not that no spec prescribes the use of this media type
> for Atom 0.3 feeds.  What matters is whether it's in use today, which
> we seem to agree is the case.  This seems an important piece of
> information that implementors should know, which is my motivation for
> asking that it be called out in the "interoperability considerations"
> section of the template.  Something like;
> 
>   Interoperability considerations: Some existing agents and feeds that
>          support the Atom 0.3 specification, make use of this media
> 	 type despite Atom 0.3 not being compatible with Atom 1.0.

In the spirit of that point about 0.3 being served with the media type
being an interop issue - what are the behaviors which will lead to
interoperation? The above text is only leads one to ask "and I should do
what here?" and doesn't say anything useful about what to do.

cheers
Bill
Permalink | Reply | 14 comments |
headers
Sam Ruby | 11 Jul 2005 15:59
Favicon
Gravatar

Re: Old application/atom+xml issues


Bill de hÓra wrote:
> Mark Baker wrote:
> 
> 
>>IMO, it matters not that no spec prescribes the use of this media type
>>for Atom 0.3 feeds.  What matters is whether it's in use today, which
>>we seem to agree is the case.  This seems an important piece of
>>information that implementors should know, which is my motivation for
>>asking that it be called out in the "interoperability considerations"
>>section of the template.  Something like;
>>
>>  Interoperability considerations: Some existing agents and feeds that
>>         support the Atom 0.3 specification, make use of this media
>>	 type despite Atom 0.3 not being compatible with Atom 1.0.
> 
> In the spirit of that point about 0.3 being served with the media type
> being an interop issue - what are the behaviors which will lead to
> interoperation? The above text is only leads one to ask "and I should do
> what here?" and doesn't say anything useful about what to do.

I'll also point out that there are atom 0.3 feeds being served with a 
mime type of text/html.  And undoubtably there will be atom 1.0 feeds so 
served.

The most we can do is to say that such things are invalid, and to work 
with the producers to correct this.

The majority of the existing atom 0.3 feeds are produced by a relatively 
few producers.  I am confident that these producers will convert over
(Continue reading)

Permalink | Reply | 12 comments |
headers
Mark Baker | 11 Jul 2005 16:45
Picon
Favicon
Gravatar

Re: Old application/atom+xml issues

On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote:
> The most we can do is to say that such things are invalid, and to work 
> with the producers to correct this.

Sounds good to me.

> The majority of the existing atom 0.3 feeds are produced by a relatively 
> few producers.  I am confident that these producers will convert over 
> quickly.
> 
> I am also committed to getting the word out quickly that atom 0.3 feeds 
> are not to be considered valid.  In particular, I plan to update the 
> feedvalidator to note this as a problem (first as a warning, and later I 
> will change this to an error).

Nice.  Thanks for your vigilance, Sam.

Mark.
--

-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com
Permalink | Reply | 10 comments |
headers
Liam Quin | 11 Jul 2005 16:47
Picon
Favicon

Re: W3C Last Call and Media Type request for comments: XQuery and XQueryX

On Thu, May 19, 2005 at 11:56:03PM +0900, MURATA Makoto wrote:
> > Please note that this is for application/xquery -- a non-XML format.
> > For application/xqueryx+xml I'll send separate mail.
> 
> I will then wait for your next mail for application/xqueryx+xml.

I just realised, in reviewing the document, that I answered you
in a way that was misleading -- sorry!

I sent two applications (application/xquery and application/xquery+xml)
in the same message.  We are dropping the optional charset parameter
for application/xquery, but for application/xquery+xml we are of
course bound by the existing rules for XML media types.

Here is the relevant extract from the text:

    MIME media type name: application
    MIME subtype name: xquery+xml
    Required parameters: none
    Optional parameters: charset

    This parameter has identical semantics to the charset parameter of
    the application/xml media type as specified in [RFC3023].

Possibly we should instead say

    Required parameters: see RFC 3023 or successor

    Optional parameters: see RFC 3023 or successor
(Continue reading)

Permalink | Reply | 2 comments |
headers
Liam Quin | 11 Jul 2005 17:17
Picon
Favicon

Re: W3C Last Call and Media Type request for comments: XQuery and XQueryX

On Thu, May 19, 2005 at 01:45:35PM -0400, John Cowan wrote:
> Liam Quin scripsit:
>>  Interchange of a database query language over the Web in its own
>>  Internet Type is likely for machine execution or to interchange
>>  files, not for reading by humans, as then text/plain might be
>>  more appropriate... but this is conjecture on my part right now.
> 
> FWIW, I think this is a Bad Thing.  Programming language content should
> go in text/plain files (despite the nasty problem with the encoding
> type imposed by text/*), so as to *discourage* browsers from attempting
> to execute them, which is a big fat security hole.

Execution of a query in this context could better be written as
evaluation of an expression; the side-effects in XQuery are very
limited, although I agree that whenever code is executed remotely
there are some serious security concerns.

> The use of text/css in HTML link elements and XML stylesheet PIs is
> essentially a hack so that browsers can decide whether to fetch the
> stylesheet, and is not consistent with the intention of IETF media
> types, which are designed to specify a minimal mapping from raw
> octets to interpretable objects such as characters or pixels.

I think this is a different case -- tect/css is a subsidiary document,
and the "type=" pseudo-attribute in a processing instruction is only
(I believe) there because the work predated widespread adoption of
XML namespaces.

Here, the XML Query document is likely to be the primary object
of transfer, not a subsidiary that applies to something else.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill de hÓra | 11 Jul 2005 17:41
Favicon
Gravatar

Re: Old application/atom+xml issues

Mark Baker wrote:
> On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote:
> 
>>The most we can do is to say that such things are invalid, and to work 
>>with the producers to correct this.
> 
> 
> Sounds good to me.
> 
> 
>>The majority of the existing atom 0.3 feeds are produced by a relatively 
>>few producers.  I am confident that these producers will convert over 
>>quickly.
>>
>>I am also committed to getting the word out quickly that atom 0.3 feeds 
>>are not to be considered valid.  In particular, I plan to update the 
>>feedvalidator to note this as a problem (first as a warning, and later I 
>>will change this to an error).
> 
> 
> Nice.  Thanks for your vigilance, Sam.

What Mark said. Now, that's the world as it might be outside the spec.
There is still proposed spec text, which I suggest is amended as follows:

[[[
Interoperability considerations: Some existing agents and feeds that
support the Atom 0.3 specification make use of this media type despite
Atom 0.3 not being compatible with Atom 1.0. Such feeds SHOULD be
considered invalid Atom 1.0.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Robert Sayre | 11 Jul 2005 20:05
Picon
Gravatar

Re: Old application/atom+xml issues


> What Mark said. Now, that's the world as it might be outside the spec.
> There is still proposed spec text

There are also draft-05, draft-06, draft-07, draft-08, and draft-09
feeds in the wild, being produced by people who aren't WG members.
There are RSS feeds served as application/atom+xml.

All of these things are obviously invalid Atom 1.0, and MUST be
considered so, as they do not reside in the correct namespace. Someone
who's read the spec is in no danger of mistaking an Atom 0.3 feed for
an Atom 1.0, and no software that bothers to check the namespace of
the root element will be fooled.

I worry that any statement like Bill's suggested text will confer
legitimacy on Atom 0.3 as long as the RFC is available. *Every*
current implementor is aware of the issue, so the short term benefit
of such text is pretty much nil. Long term, the text will actually be
harmful.

So, -1 to mentioning Atom 0.3 at all.

Robert Sayre
Permalink | Reply | 4 comments |

Gmane