parameter for content-type

[pdowler]

In DataLink, we specify a parameter to add to the VOTable mime type to tell clients that the table contains "datalinks":

application/x-votable+xml; content=datalink

Over in the DataLink discussions about adding params to other content-type values (eg in the content_type column), we found out that this really goes against the spirit of the mime type RFC 2045 and that params should be defined by the spec that owns the type. So, this is a request for VOTable to add an allowed mime type parameter content that other specs can define values for. It would thus be open ended but clients would know to anticipate the param in some cases.

[mbtaylor]

This appears to be more or less a duplicate of #15

[mbtaylor]

Note there may be other uses of the content parameter than content=datalink. Laurent Michel was using content=mivot in his MIVOT Stack talk in Görlitz.

[pdowler]

Given the nature of VOTable and it's use in various ways, I think just sanctioning a content parameter that specific table structures (aka other standards) can use is probably sufficient.

Having said that, the content=mivot usage is slightly more generic and doesn't say directly what the results table contains... so in principle one might have content=ObsCore (eg from SIAv2 or DAP) and content=mivot if the VOTable also contains MIVOAT annotations. So should we be careful to say that content can be repeated and what that means, or not allow it? One might want to say two things about the content...

I have not looked up whether mimetype params can have multiple values or not, but it seems like it is overloading a very primitive construct so I would not be surprised to find it is and should be limited.

[msdemlei]

On Tue, Nov 18, 2025 at 06:04:06PM -0800, Patrick Dowler wrote: pdowler left a comment (ivoa-std/VOTable#26) Having said that, the `content=mivot` usage is slightly more generic and doesn't say directly what the results table contains...

Right, and I don't think there's much of a reason to have something like that once Laurent is done with his testing; after all, the annotations shouldn't disturb any client not interested in it (provided they follow our schema versioning policies). Put another way: If we rely on DM annotations for epoch propagation (or photometric metadata or whatever else), then they should certainly be the default and not something to be actively switched on by clients. So, while I agree that content=datalink certainly is not the only content parameter we will see, mivot shouldn't be the other example. It's nothing more than a test artefact.

[mbtaylor]

Yes I just put content=mivot there as an example of another value than datalink for the purposes of this discussion, i.e. to show it has a more general usage. I agree that the definition in VOTable should just describe what the content parameter is for rather than attempting to enumerate some or all values it can take.

I don't see anything in RFC 2045 that says parameters can or cannot be repeated, but I don't remember ever seeing a repeated one; I'd be against allowing multiple content parameters in a single content-type without some quite strong motivation.

[mbtaylor]

Pat was asking on Nov 19:

I have not looked up whether mimetype params can have multiple values or not, ...

They can't. From RFC 6838 section 4.3:

It is an error for a specific parameter to be specified more than once.