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

[Martin J. Dürst <[e-mail]>]

Hello Todd,

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

On 2018/10/26 09:57, Todd Hubers wrote:
> 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.

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/.

> 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.

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.

> 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.

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 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._

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.

> 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)
>