Subject: [Doh] Web Convergence - is there a document/RFC for this apparent direction?

From: Todd Hubers <[email-masked]>
Date: Fri, 26 Oct 2018 11:57:56 +1100

Hi All,

Is there a document/RFC about the IETFs collective general movement toward
re-standardisation of things like DNS (DOH), SMTP (JMAP), and maybe others
using Web/HTTP/JSON?

I read the introduction of DoH [RFC8484], and noted there was no reference
there, so such a document probably doesn't exist.

Instead, it could read something like "Web Convergence is desirable
[RFCXXXX]", and that RFC could be very comprehensive in the collective
decision about this direction. It would critically help in determining when
a current standard should be considered for Web Convergence.

I believe it would be something to be referenced in the charter of such a
WG, to clarify WHY the work is being completed, in addition to the other
good reasons. Even if we don't have an RFC, this idea does need a solid
name/label.

I have initial ideas for the content of such a Web Convergence RFC
[Appendix 1], and what it might be ultimately called [Appendix 2]

(I am also new to IETF generally, so I'm still learning. But I like
learning by doing._

Thanks,

Todd Hubers

---

Appendix 1

For rebuilding of older standards the web way; OR, building new standards
the web way. The reasons should be the same.

Initial ideas for reasons to be collated in such a document/rfc:

- Accessible directly by web applications (javascript), removing the need
to push via a specialised application server adaptor service (eg. HTTP to
SMTP)
- The reuse of standard web sysops tools (eg. nginx, certificate
management, services like CloudFlare and more)
- The reuse of standard web frameworks and libraries (eg. header parsing,
asynchronous threads)
- Reducing the diffusion of open source development contribution
(redefining the same functions in different standards, and different source
code is inefficient).
- Additional features available from current and future web standards (eg.
redirect, media-type negotiation, compression, multiplexing, proxying,
caching, authentication, Header Parsing, URIs, well-named folders,
Identity, Semantics, etc..)
- More secure with exactly the same security model as web - (eg. no plain
text email transmission)
- All security/firewalls leveraging accumulated PORT 80/443 and HTTP
intelligence.

---

Appendix 2

Possible names for this process

- Web Recasting
- Web Convergence
- Http Convergence (specifically HTTP of Web Convergence)

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 26 Oct 2018 01:30:46 +0000

Hello Todd,

This is just a personal opinion, but based on more than 20 years of 
experience with various standards organizations including the IETF.

> there, so such a document probably doesn't exist.

I guess you're right. But there may be documents that are somewhat 
related. In particular, I'm thinking of 
https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/.

> a current standard should be considered for Web Convergence.

The IETF is (at least officially) a collection of individuals. Many of 
these individuals see trends like the one you bring up here. But the 
IETF as a whole isn't organized or empowered to adapt great trends and 
then force everybody to follow them. Where that has been tried, it has 
usually not worked extremely well.

Other standards organizations may do more of such "overall direction" 
documents, but in general, I don't think they have too much success with 
them.

> good reasons. Even if we don't have an RFC, this idea does need a solid

WGs get formed because enough individuals (and often companies that 
employ them) are interested in getting some standardization work done. 
That work may be way ahead of a trend, may be in one of the current 
trends, may be way behind a trend, or completely unrelated to any trend.

> (I am also new to IETF generally, so I'm still learning. But I like

Everybody (including you) can submit an Internet Draft (except this 
week). So writing up your ideas and submitting a draft may be a good 
idea. My personal advice would be to be more descriptive and less 
predictive or prescriptive.

Regards,   Martin.

---

From: Todd Hubers <[email-masked]>
Date: Fri, 26 Oct 2018 12:57:05 +1100

Hi Martin,

Thanks for your time. At the very least, I seek validation of the necessity
for this from others, while I refine my communication of the ideas I'm
trying to express.

I have been reading a lot of material, and also the intro youtube videos.
So I do have a good grasp of the correct approach. I understand the
fundamental principles of no voting etc., This is why I was careful to
write "collective decision of direction" - such a direction isn't
necessarily conscious/formal. However, It would have been better if I wrote
"..that RFC could be very comprehensive in cataloguing the reasons why Web
Convergence is desirable...".

I don't expect such a document to be prescriptive at all. As you say, there
is no "decision", although there is an observed "direction" in some IETF
proposals and in the industry broadly; this is a tool for decision making
and a reference for brevity. It would be a body of work that could be
referenced, helping to establish why any organisation would write their
standard leveraging Web Standards (and why not).

https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ is a
fantastic reference, this is exactly the kind of document I was hoping to
find. It's a great starting point, if not the exact thing, I was
describing. I'll need to spend time and read it in more detail. It might
need to be broadened to "Web"; either directly or via a separate new
Internet Draft. JMAP is a good example of why such broadening may be
useful: The JMAP standard document doesn't actually reference HTTP, I
believe it's more about JSON schema than HTTP mechanisms (or perhaps such
mechanisms are in other standards that I haven't read yet) - although the
charter does mention HTTP - perhaps HTTP is a missing component from the
JMAP standard.

If I had a fresh stab of a description of a new Internet Draft, it would be
"Choosing whether or not to build new standards upon Web Standards". The
title "Web Convergence" is probably too prescriptive, "Building Protocols
with Web Standards" might be an appropriate title, or "Building Standards
based on Web Standards".

So with my clarifications above, I would welcome any further criticisms or
support, to help guide me in coming weeks.

Thanks,

Todd

-- 
--
Todd Hubers

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 25 Oct 2018 22:57:47 -0400

Todd Hubers writes:
> Is there a document/RFC about the IETFs collective general movement
> toward re-standardisation of things like DNS (DOH), SMTP (JMAP), and
> maybe others using Web/HTTP/JSON?

I'm curious about the use of the term "re-standardization" here, and
suspect my interpretation of it is different than what you intended.
I would take the word to mean redefinition, and in that light I'd have
a really hard time defining DoH as the DNS being re-standardized.  How
did you mean it?

---

From: Todd Hubers <[email-masked]>
Date: Fri, 26 Oct 2018 14:12:14 +1100

Hi Dave,

This is simply a poor choice of words on my part. I see DoH as a new
standard that leverages the DNS binary protocol in the message area. I used
the term "re-standardization" to mean a new standard that redefines and the
way an older one worked. Most significantly, DNS uses another port for
example, but DoH would use port 80/443.

So "redefine" is probably better, but "new standard" is probably the best,
because it isn't directly superceding - the two standards will live on side
by side.

Also, "recasting" is another idea I had with respect to DoH. A lot of the
same "material" is used, but in another form.

Thanks,

On Fri, 26 Oct 2018 at 13:58, Dave Lawrence <[email-masked]> wrote:

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

-- 
--
Todd Hubers