Re: [Uta] STS directive registry: separate or shared?

[Aaron Zauner <[e-mail]>]

Hi,

> On 14 Apr 2016, at 23:54, Chris Newman <[e-mail]> wrote:
> 
> Right now we have 3 STS proposals: HSTS, SMTP relay STS and MUA STS (DEEP).
> 
> HSTS described its extensibility model, but punted on actually creating a registry. A registry covering HSTS would be useful because there’s at least one limited-use directive in the wild in addition to those in the HSTS base spec. MUA STS currently describes an extensibility model and creates a registry just for itself. SMTP relay STS is missing both an extensibility model and registry, although Viktor has made a compelling case that we we want to be minimal on SMTP relay STS directives (at least initially).

This makes a lot of sense.

> 
> There are two ways to move forward:
> 
> 1. Each protocol is responsible for it’s own extension model and registry. This has the advantage of getting MUA STS done sooner, but we’ll probably end up with 2 or 3 separate registries with some redundancy and potential for semantic conflicts in STS directives with the same name between protocols.
> 
> 2. We create a combined STS registry that includes a protocol-applicability field for each directive. Some directives would be multi-protocol (e.g., max-age may be shared between HSTS and SMTP relay STS), most would be single-protocol initially (that could change later). One advantage to this approach is it gives us a place to include some prose about why STS proposals are different and why different applicability is important. But this would take a bit longer and mean the WG would have another draft. This would make life slightly simpler for SMTP relay STS as it would just have to describe its extensibility model and point to the shared registry. If we do this, I am willing to co-author the shared-registry spec and Jeff Hodges (co-author of HSTS spec) is also willing to co-author the spec.
> 
> I lean slightly towards option 2, but we need a WG rough consensus to pursue that option as it’s a fairly significant change to MUA STS. Comments?

But it's a good point that #1 would get MUA-STS out of the door sooner, which is something I'd very much like to see deployed. Difficult, but I think option #2 is the way to go.

Thanks for working on this,
Aaron