Subject: [weirds] Issue 4: http media types in RDAP replies

From: "John Levine" <[email-masked]>
Date: 16 Mar 2013 19:30:50 -0000

My suggestion for 4.1 is to tighten this up and mandate that clients
say what they want:

Current:

   Clients SHOULD put the media type of the format they desire in the
   Accept header field.

      Accept: application/rdap

   Servers SHOULD respond with an appropriate media type in the Content-
   Type header in accordance with the preference rules for the Accept
   header in HTTP [RFC2616].

      Content-Type: application/rdap

   Clients MAY use a generic media type for the desired data format of
   the response (e.g. "application/json"), but servers SHOULD respond
   with the most appropriate media type (e.g. "application/rdap").  In
   other words, a client may use "application/json" to express that it
   desires JSON or "application/rdap" to express that it desires RDAP
   specific JSON, but the server would respond with "application/rdap".

Proposed:

   RDAP clients MUST include an Accept: header specifying
   application/rdap, application/json, or both.  Servers receiving an
   RDAP request MUST return an entity with Content-Type application/rdap.

   This specification does not define the responses a server returns to
   a request with any other media types in the Accept: header, or with no
   Accept: header.  One possibility would be to return a response in
   a media type suitable for rendering in a web browser.

This is deliberately much less flexible, to make it easier for to
interoperate.  If anyone has a plausible scenario in which an RDAP
client can't provide an Accept header, or a server can't respond with
application/rdap content type, please speak up now.

R's,
John

PS: curl and wget have no problem sending Accept: headers.

---

From: Jean-Philippe Dionne <[email-masked]>
Date: Wed, 20 Mar 2013 11:54:57 -0400

> application/rdap content type, please speak up now.

I agree with the proposed text.   We must also add a request to IANA for 
the 'application/rdap' in the 'media-types' registry.  See below the 
filled template taken from draft-ietf-appsawg-media-type-regs-14

What about the +json suffix?
 From draft-ietf-appsawg-media-type-regs-14#section-3, we can read:
"Media types that make use of a named structured syntax SHOULD use the
  appropriate registered "+suffix" for that structured syntax when they
  are registered. "

Type name: application

Subtype name: rdap+json

Required parameters: none

Optional parameters: none

Encoding considerations: binary

Security considerations: none

Interoperability considerations: N/A

Published specification: draft-ietf-weirds-using-http-01

Applications that use this media type: RDAP Applications

Fragment identifier considerations: N/A

Additional information:

	Deprecated alias names for this type: N/A
	Magic number(s): N/A
	File extension(s): N/A
	Macintosh file type code(s): N/A

Person & email address to contact for further information: Andy Newton 
<[email-masked]>

Intended usage: COMMON

Restrictions on usage: None

Author: Andy Newton

Change controller: TBD

Provisional registration? (standards tree only): Yes

Thanks
Jean-Philippe

---

From: Andy Newton <[email-masked]>
Date: Wed, 20 Mar 2013 16:22:07 +0000

We already do that in json-response, but I'm happy to move it to
using-http.

Also, we originally had the +json suffix and took it out. But since you've
found some guidance on the use of the suffix, it is probably wise to add
it back in.

-andy

---

From: Tony Hansen <[email-masked]>
Date: Wed, 20 Mar 2013 12:59:21 -0400

The draft mentioned below was recently published as RFC 6838:
    Media Type Specifications and Registration Procedures. N. Freed, J.
Klensin, T. Hansen. January 2013.

The actual registration of +json can be found in RFC 6839:
    Additional Media Type Structured Syntax Suffixes. T. Hansen, A.
Melnikov. January 2013.

        Tony Hansen
        [email-masked]