Subject: [Extra] Discussion of charter and SMTP related work

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 08 Nov 2018 07:09:15 -0500

Apologies for the flood, this is the last one, I promise! At least, it's the last checkbox ACTION item I have from today's meeting... 
 
Hi All, 
 
When we chartered this working group, we had a flood of work, and we deliberately excluded SMTP and MIME from our charter in order to stay focused. The flood has mostly abated now, and we find ourselves considering whether to open up our scope to accept some other work which has interest (fixing the fact that 822 is an obsolete INTERNET STANDARD replace by 5322 which is only a DRAFT STANDARD - which doesn't even exist any more, and also fixing accumulated errata). There's also some MIME work which could be tightened up and better described. 
 
The choices before us are roughly: 
 
a) spin up a new working group to take on the SMTP/MIME work 
b) recharter this group 
 
It's expected that much the same people will be involved regardless, so we'd be keen to hear arguments for or against these options. Please reply to this email with your opinions. 
 
Thanks, 
 Bron. 
 
-- 
 Bron Gondwana, CEO, FastMail Pty Ltd 
 [email-masked]

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 8 Nov 2018 06:49:12 -0800

Would expanding the scope of this group open it up more to taking on the 
CLIENTID extensions?

On 2018-11-08 4:09 a.m., Bron Gondwana wrote:
> Apologies for the flood, this is the last one, I promise!  At least, 
> it's the last checkbox ACTION item I have from today's meeting...
> 
> Hi All,
> 
> When we chartered this working group, we had a flood of work, and we 
> deliberately excluded SMTP and MIME from our charter in order to stay 
> focused.  The flood has mostly abated now, and we find ourselves 
> considering whether to open up our scope to accept some other work which 
> has interest (fixing the fact that 822 is an obsolete INTERNET STANDARD 
> replace by 5322 which is only a DRAFT STANDARD - which doesn't even 
> exist any more, and also fixing accumulated errata).  There's also some 
> MIME work which could be tightened up and better described.
> 
> It's expected that much the same people will be involved regardless, so 
> we'd be keen to hear arguments for or against these options.  Please 
> reply to this email with your opinions.
> 
> Thanks,
> 
> Bron.
> 
> --
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
> 

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 08 Nov 2018 10:18:52 -0500

Hi Michael, 
 
It's possible, but I don't think the objections that were raised at Montreal have changed since then. 
 
We actually discussed how that session went and whether there's anything we could have done in terms of preparation to help set your expectations on how the IETF process works and that we're more interested in the problem to be solved and the technical requirements and challenges than in a particular pre-defined solution. 
 
We'd definitely love to keep talking about the problem that CLIENTID is looking to solve in the EXTRA group, or Alexey might have suggestions for a different venue for security work (which is not currently in our scope). We definitely see CLIENTID as being largely security related. 
 
Bron.