MOC standard identifiers

[Markus Demleitner]

Dear Apps,

The VODataService 1.2 WD says that when a footprint url in the
registry has an ivoid attribute set to ivo://ivoa.net/std/moc,
a FITS MOC must come back.

While this is a bit of an abuse of footprint/@ivo-id (we'll have to
work that out in Registry -- a cleaner alternative would be to
introduce a standardID attribute, and if you have opinions on this, 
feel free to speak out), my current qualm with this is that it is
conceivable that data providers may one day want to use other MOC
representations on footprint endpoints, and then we'd have to hack
around the broad statement "it's a MOC".

What I'd prefer: MOC defines two standard keys, perhaps even
versioned, as in 

* ivo://ivoa.net/std/moc#fits-1.0
* ivo://ivoa.net/std/moc#ascii-1.1

I believe the language to state this is minor enough to add it during
MOC RFC, and I'm happy to edit the registry record so it reflects
this.

The one thing that again hurts me a bit with this is that what we're
doing here is really already covered by the well-known IETF media
types, and in a way it might be smart, too, to define that when ASCII
MOCs are transmitted in a MIME context, they should be declared as 

text/plain;content=MOC,

whereas FITS MOCs would be

application/fits;content=MOC.

If that were adopted, in VODataService we could keep the plain ivoid
(which is already declared by a number of resources; but I'd say
not so many that it's unreasonable to fix it) and warn implementors
that any approved MOC serialisation can come back from them and they
need to look at the media type (which clients have because footprint
URLs always point to HTTP endpoints).

Thoughts or advice, anyone?

        -- Markus