Hi,

> On 14 Apr 2016, at 23:54, Chris Newman <[email protected]> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to