MIME Media type syntax for atom:link/@type and atom:content/@type

[Brian Smith-19]

Can atom:link/@type and atom:content/@type reference media types with
parameters like "application/atom+xml;type=entry"? If so, what is the syntax
supposed to be?

Currently, I am using RFC 2616's media-type syntax so that these attributes
have a syntax consistent with HTTP Content-Type headers, and because RFC
5023 already re-uses the RFC 2616 media-range syntax. Is anybody handling it
any other way?

RFC 4287 references RFC 4288 for the syntax of atom:link/@type and
atom:content/@type. However, RFC 4288 doesn't define a syntax for media
types with parameters. I suppose we are supposed to use something similar to
what RFC 2045 and RFC 2616 use, but each of those have different grammars
for this construct. The parts of the syntax that RFC 4288 *does* define are
more restrictive than the syntax used by RFC 2616, but RFC 4288's
constraints are for registered MIME types, not all MIME types.

Regards,
Brian

[James M Snell]

Brian Smith wrote:
> Can atom:link/@type and atom:content/@type reference media types with
> parameters like "application/atom+xml;type=entry"? If so, what is the syntax
> supposed to be?
>

Of course. The syntax is nothing special:

   <link type="application/atom+xml;type=entry" href="..." />

Quoted parameters will need to be escaped of course...

   <link type="application/atom+xml;type="entry"" href="..." />

- James

> Currently, I am using RFC 2616's media-type syntax so that these attributes
> have a syntax consistent with HTTP Content-Type headers, and because RFC
> 5023 already re-uses the RFC 2616 media-range syntax. Is anybody handling it
> any other way?
>
> RFC 4287 references RFC 4288 for the syntax of atom:link/@type and
> atom:content/@type. However, RFC 4288 doesn't define a syntax for media
> types with parameters. I suppose we are supposed to use something similar to
> what RFC 2045 and RFC 2616 use, but each of those have different grammars
> for this construct. The parts of the syntax that RFC 4288 *does* define are
> more restrictive than the syntax used by RFC 2616, but RFC 4288's
> constraints are for registered MIME types, not all MIME types.
>
> Regards,
> Brian
>
>

[Brian Smith-19]

James M Snell wrote:

> Brian Smith wrote:
> > Can atom:link/@type and atom:content/@type reference media
> > types with parameters like "application/atom+xml;type=entry"?
> > If so, what is the syntax supposed to be?
>
> Of course. The syntax is nothing special:
>
>    <link type="application/atom+xml;type=entry" href="..." />
>
> Quoted parameters will need to be escaped of course...
>
>    <link type="application/atom+xml;type="entry""
> href="..." />

I understand the general syntax. However, the details are what I am unsure
about. :

1. What leading/trailing/internal whitespace is allowed? (Right now I allow
all this whitespace, just as RFC 2616 does for Content-Type.)

2. What characters are allowed in a parameter value? (Currently, I do as RFC
2616 does.)

3. What escaping mechanism is used for quoted parameter values? For example,
how would one represent a parameter value containing a '"'? (Currently, I
use the backslash as the escape character like RFC 2616 does.)

4. How do you handle codepoints above \u007f and especually above \u00ff in
parameter values? Right now I allow only characters that are in ISO-5591-1.

5. Should we really restrict parameter names to RFC 4288 reg-name? (Right
now, I use the RFC 2616 token production, which is more general.)

I have a validator in my software which accepts every valid entry and
rejects every invalid entry. It already handles all these edge caes but I
would like to know if anybody disagrees with any of the decisions I have
made.

Thanks,
Brian