On Fri, Sep 19, 2008 at 11:35 AM, Antone Roundy <[EMAIL PROTECTED]> wrote: > Just to be sure this is clear, "media=print" is something I invented for > this discussion. If "media=print" were a valid parameter for text/html, > then yes, as I understand it, that would be legal in Atom -- I can't see any > reason why it wouldn't or shouldn't. > Well, that's not quite what I was asking (although raises another question) -- I meant text/html and text/html;media=print are unique content-types in the eyes of an Atom validator (ignoring validity with regards to RFC2854 for the sake of argument) and can therefore both be used as link rel="alternate" types in the *same* Atom context (i.e. feed or entry). Is this true?
But the other question would be, who is that determines the validity of parameters for mime-types? Reading the RFCs this seems a little ambiguous. There are required parameters and optional parameters, but I don't see anything where providing a parameter that isn't set in the RFC is illegal or somehow invalid. I will be the first to admit that I have not read RFCs 1521, 1522, 3023 and all their kin from cover to cover, but would like to hear from somebody that feels they can confidently answer this. RFC3023 sort of brings this up in the appendices (A.5-A.10), but I am having trouble understanding the implications of using custom parameters to disambiguate representations in an ambiguous mime-type (of course realizing that agents that are unaware of any convention being used wouldn't be able to use it). And the reason why I bring this up, specifically, is because I had planned on using a method similar to this to allow alternate links to atom feeds containing different metadata formats *of the same resources* within entry:content. Corrections and guidance welcome. -Ross.
