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

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Jun 2015 13:26:06 +1000

See: <https://github.com/mnot/I-D/issues/107>

This is the last open issue we have from the TAG review. 

At this point, I'm inclined to go with the approach discussed in the issue — moving extensions to a separate object (name TBD).

Any thoughts on that? I know that this may not be compatible with some existing uses of the draft, but I think we can word it in such a way that they can transition without too much pain.

Cheers,

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Jun 2015 10:55:35 -0700

I think that this issue is best resolved by - at most - creating a registry
for names.

RFC 6648 describes how "x-smell" or "google-smell" leads to problems, and
that same advice applies equally to creating a separate bucket (i.e.,
"x.smell").
On Jun 21, 2015 8:26 PM, "Mark Nottingham" <[email-masked]> wrote:

> At this point, I'm inclined to go with the approach discussed in the issue
> — moving extensions to a separate object (name TBD).
>
> Any thoughts on that? I know that this may not be compatible with some
> existing uses of the draft, but I think we can word it in such a way that
> they can transition without too much pain.
>
> Cheers,
>
>
> --
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Jun 2015 09:35:40 +1000

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. 

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

Cheers,

> On 23 Jun 2015, at 3:55 am, Martin Thomson <[email-masked]> wrote:
> 
> I think that this issue is best resolved by - at most - creating a registry for names.
> 
> RFC 6648 describes how "x-smell" or "google-smell" leads to problems, and that same advice applies equally to creating a separate bucket (i.e., "x.smell").
>