Subject: Re: [apps-discuss] Extension model for http-problem

From: Mark Nottingham <[email-masked]>
Date: Wed, 15 Jul 2015 14:56:49 +0200

> On 23 Jun 2015, at 1:35 am, Mark Nottingham <[email-masked]> wrote:
> 
> A completely different way of doing it would be to require that a new version that does that to use a different media type. 

I'm kind of warming to this approach. Thoughts?

--
Mark Nottingham   https://www.mnot.net/

---

From: Dave Cridland <[email-masked]>
Date: Wed, 15 Jul 2015 14:33:08 +0100

On 23 June 2015 at 00:35, Mark Nottingham <[email-masked]> wrote:

> The difference here is that extensions are explicitly name spaced by the
> type URI; there is no concept of an extension that spans multiple types
> (each type would have to "opt into" it explicitly).
>
> As such, the problem (see what I did there?) that needs to be addressed is
> handling the case where a new version of the spec defines a new standard
> extension, and we want to avoid conflicts with existing extensions.
>
>
If I understand correctly, you're talking in terms of what happens where a
future version of application/problem defines new top-level keys. A key
issue here is that in your "account" case, the variables "balance" and
"account" could get trampled on. These variables are indistinguishable from
the extensions to the problem format itself from a syntactic point of view;
I think this represents a long-term problem.

Instead I think per-type variables need to be within a different container:

{
  type: "http://...",
  vars: {
     balance: 30,
     accounts: []
  }
}

In other words, I agree with your initial hunch as to the solution.

> A completely different way of doing it would be to require that a new
> version that does that to use a different media type.
>

This works, of course, but means you've got a clear compatibility break,
which seems like a heavy penalty to pay (and one we'd likely try to work
around as a result).

Dave.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 15 Jul 2015 16:16:37 +0200

> On 15 Jul 2015, at 3:33 pm, Dave Cridland <[email-masked]> wrote:
> 
> If I understand correctly, you're talking in terms of what happens where a future version of application/problem defines new top-level keys.

Yes - although it's not certain that will happen.

> A key issue here is that in your "account" case, the variables "balance" and "account" could get trampled on. These variables are indistinguishable from the extensions to the problem format itself from a syntactic point of view; I think this represents a long-term problem.

Indeed.

> This works, of course, but means you've got a clear compatibility break, which seems like a heavy penalty to pay (and one we'd likely try to work around as a result).

How so? The producer of a problem can opt into supporting the new format depending upon its needs. It's true that you have to negotiate the format, but we already have a way to do that in HTTP.

My reluctance to make the change now is partially due to the desire to avoid breaking existing users of the format; for better or worse, we have a fair number of implementations as well as users (probably because it's sat out there for so long).

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Jul 2015 09:41:23 -0700

> I'm kind of warming to this approach. Thoughts?

As long as you don't attempt to proscribe ad-hoc additions I think
that it's a fine idea.

---

From: Erik Wilde <[email-masked]>
Date: Thu, 16 Jul 2015 15:31:13 -0700

hello.

> As long as you don't attempt to proscribe ad-hoc additions I think

just throwing it out as another possibility: extensions could also use a 
profile media type parameter (a la RFC 6906), identifying the specific 
flavor they are using. vanilla consumers could still look at the 
http-problem fields as usual, and those supporting the specific profile 
would know which rules to follow when looking at extensions.

it's basically the same as the "namespace URI in the format" idea, only 
that this time, that URI can be exposed as part of the media type. for 
this to work, the profile media type parameter would have to be defined 
for the http-problem media type, and there probably would have to be a 
"SHOULD" saying that extensions should be exposed that way.

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 |