Subject: format of atom:link/@type

From: Julian Reschke <[email-masked]>
Date: Fri, 15 May 2009 15:16:14 +0200

Hi,

looking at 
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.3>...:

"4.2.7.3 The "type" Attribute

On the link element, the "type" attribute's value is an advisory media 
type: it is a hint about the type of the representation that is expected 
to be returned when the value of the href attribute is dereferenced. 
Note that the type attribute does not override the actual media type 
returned with the representation. Link elements MAY have a type 
attribute, whose value MUST conform to the syntax of a MIME media type 
[MIMEREG]."

Now the link to MIMEREG (RFC 4288) doesn't really help, because that 
document doesn't define the syntax.

So, finally, the question: does @type allow a media type *plus* parameters?

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 15 May 2009 08:42:53 -0500

> So, finally, the question: does @type allow a media type *plus*

See http://www.imc.org/atom-syntax/mail-archive/msg20665.html for the
previous discussion of this issue.

In my parser & validator, I use the HTTP media-type grammar. When producing
Atom documents I use HTTP media-type grammar, but I make sure not to add any
gratuitous parameters, whitespace, or unnecessary quoting.

I believe that is the only sensible way to handle it, because
atom:link/@type should (be able to) match the Content-Type of whatever it is
linking to.

There are other similar issues too. For example, some parts of various Atom
specifications use a comparison function for atom:link/@type that isn't
defined. I do the comparison the same way as we do in HTTP (case-insensitive
except for quoted values, whitespace normalized, parameter-for-parameter
comparisons). Another example is atom:link/@length which doesn't have a
normative grammar. I use "DIGIT+" as the grammar in my projects.

Regards,
Brian

---

From: Richard Salz <[email-masked]>
Date: Fri, 15 May 2009 09:59:16 -0400

> So, finally, the question: does @type allow a media type *plus* 
parameters?

According to RFC 2045, the type is foo/bar and the parameters are not part 
of the type.  So I'd say no.

        /r$

--
Visiting Member, IBM Academy
STSM, DataPower Chief Programmer
WebSphere Appliance Architect
http://www.ibm.com/software/integration/datapower/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 May 2009 16:04:03 +0200

Richard Salz wrote:
> ...

But the spec links to RFC4288, which doesn't say anything about the 
syntax...

And I think most people expect a media type to be "what MIME and HTTP 
use in the Content-Type header"...

BR, Julian

---

From: Richard Salz <[email-masked]>
Date: Fri, 15 May 2009 10:11:31 -0400

> But the spec links to RFC4288, which doesn't say anything about the 

That seems to be a bug in the spec.

> use in the Content-Type header"...

I would not disagree with you, but something like a poll would be nice :)

        /r$

---

From: Erik Wilde <[email-masked]>
Date: Fri, 15 May 2009 10:15:59 -0700

> normative grammar. I use "DIGIT+" as the grammar in my projects.

are these things discussed in an erratum or in some other well-know 
place or document? http://www.rfc-editor.org/errata_search.php?rfc=4287 
does not show any atom errata, and the things you are mentioning 
(undefined comparisons, missing grammars) should definitely be recorded 
somewhere, shouldn't they?

cheers,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 15 May 2009 14:29:17 -0500

Erik Wilde wrote:
> Are these things discussed in an erratum or in some other well-know

At one point I had collected a bunch of minor issues like this with RFC 4287
and RFC 5023, and I even shared a few on the list in the past. After trying
to work with AtomPub for a while I've realized that AtomPub is a useless
standard and Atom usually causes more problems than it solves. I may be able
to dig up the list of issues if somebody else is interested in doing
something with them. 

- Brian

---

From: Erik Wilde <[email-masked]>
Date: Fri, 15 May 2009 16:32:45 -0700

hello.

> to dig up the list of issues if somebody else is interested in doing

i think it would be very useful to have such a list, and to formally 
file them as errata (if discussions on the relevant lists establish that 
they indeed are areas where the current specs lack necessary details). 
so if you could send a list of atom and atompub issues to the relevant 
lists, that could be the start of a very useful discussion. i don't know 
how many people look up RFC errata and my guess is not very many (the 
IETF could do a better job of publishing related material, i think), but 
at least there is a well-defined place where you can find them.

http://dret.net/rfc-index/ is my rather simplistic attempt (refreshed 
weekly) to make the IETF documents a bit more accessible, but there is a 
lot that could be improved. just out of curiosity: is there a list of 
machine-readable resources (such as the XML RFC index) that one could 
use to improve access to IETF information resources by building a bit 
more sophisticated web pages from it?

thanks,