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

[Todd Hubers <[e-mail]>]

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

On Fri, 26 Oct 2018 at 12:30, Martin J. Dürst <[e-mail]>
wrote:

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


-- 
--
Todd Hubers