MOC standard identifiers

[Markus Demleitner]

Hi Pierre,

On Thu, Jun 13, 2019 at 12:16:23PM +0200, Pierre Fernique wrote:
> I would prefer to avoid to specify the MOC serialization detail returned by
> the data provider in the VO registry. Concretely, just to remove the "FITS"
> word in the VODataService 1.2 WD and let the HTTP content-type does the job
> as suggested by Markus (text/plain;content=MOC and
> application/fits;content=MOC)
> 
> => "/when a footprint url in the registry has an ivoid attribute set to
> ivo://ivoa.net/std/moc, a MOC must come back./"

As you can imagine, I like that a lot.  So much, in fact, that I've
put it into rev. 5510 of VODataService in volute.

But that, of course, would make it quite desirable to at least
mention the media types in the MOC specification.

Perhaps you could add another paragraph to 2.3.1

  Media type:

  The RFC 2046 media type for FITS-serialised MOCs is
  application/fits.  Services are encouraged to qualify the media
  type with a content=MOC parameter.  Thus, the recommended full form
  of a FITS MOC's media type is

    application/fits;content=MOC

And analogously to 2.3.2:

  Media type:

  The RFC 2046 media type for ASCII-serialised MOCs is
  text/plain.  Services are encouraged to qualify the media
  type with a content=MOC parameter.  Thus, the recommended full form
  of an ASCII MOC's media type is

    text/plain;content=MOC


As I said, I'd hope that's still within the limits of what can be
changed during RFC.

Thanks,

             Markus