Subject: Re: [apps-discuss] returning something from http 402

From: Erik Wilde <[email-masked]>
Date: Tue, 07 Jul 2015 15:48:07 -0700

hello melvin.

On 2015-06-26 14:01 , Melvin Carvalho wrote:
> On 24 June 2015 at 18:45, Erik Wilde <[email-masked] <mailto:[email-masked]>> wrote:
>         On 24 June 2015 at 16:10, Ken Murchison <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>              Perhaps leverage
>         https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-00
>         It's great that RDFa is mentioned in the doc.  I suspect the
>         serializations I would be working with would be JSON-LD and Turtle.
>     currently, the canonical model is defined in JSON. appendix a talks
>     about how to represent that model in XML. appendix b talks about
>     "other metamodels" and mentions RDF in passing, simply as one
>     example of those other metamodels. it would be possible to add more
>     details about how to use the canonical model in RDF-land, so that
>     there would be no doubt *how* to represent the canonical model in
>     RDF. if there's any interest, that's something that could be done in
>     an additional appendix, and talking about how that would look in
>     JSON-LD as one RDF representation then also would be pretty
>     straightforward.
>
> The document you made seems a good fit, do you have thoughts on:
> 1. The RFC is 4xx and I'd like to do something 402 specific

i'd say that media types and status codes are orthogonal. sure you can 
design something that's specific for a use case (such as payment info), 
but imho it would be strange to define media types in any way that ties 
them to specific status codes.

> 2. Thoughts on redirecting to a machine readable representation vs
> returning a machine readable representtion

that's independent from the representation you want to return, right? 
redirect if that's what you want to do (i.e., telling clients about a 
different URI than the one they were requesting), or return something if 
the URI is the one clients should be using.

in the general draft-ietf-appsawg-http-problem use case, you want to 
inform clients about a problem with that particular resource, so you 
probably won't redirect.

however, i could easily imagine that a 402 response using 
draft-ietf-appsawg-http-problem might have a link in there that clients 
could use to initiate a payment process. that would not be one of the 
standard members, but an extension member.

> 3. General thoughts on mime types -- I may be trying to request non JSON
> paid media e.g. html or video, and the client may not be expecting the
> mime type it gets -- I really need to think through this point more or
> make a proof of concept

i don't think there's anything special here. there are plenty services 
out there that return HTML 4xx pages when you request something else.

afaict, http://tools.ietf.org/html/rfc7231#section-5.3.2 specifically 
allows a server to disregard an Accept header field if there is no match 
for the response it wants to send.

> Would love to hear thoughts.  If there's a better place to discuss this
> e.g. the HTTP WG, pls let me know.

my guess is that this list is fine, but it has many subscribers. so if 
there are specific issues around using draft-ietf-appsawg-http-problem, 
then maybe better use mark's github for raising issues:

https://github.com/mnot/I-D/tree/master/http-problem

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |