On Mon, 23 Jul 2018 07:12:50 -0600, you said:
> Quoting valdis.kletnieks@xxxxxx:
>
> > On Sat, 21 Jul 2018 07:13:42 -0600, pradeep@xxxxxxxxxxxxxxxxx said:
> > 1) No definition of "WWW Brain".
> I dont accept your answer. WWW and software has evolved with Artificial intelligence
> big companies like google use Artificial intelligence.
And oddly enough, Google is able to use this AI without needing an httpi://, and
browser extensions are able to do similar, also without needing an httpi://
Which is why you need to explain exactly why the IETF should bother with
dealing with these drafts.
> I would say i dont have to
> define it for engineers. Its Intelligence of Artificial intelligence i am meaning.
> You have to answer me as a WWW user and not just an engineer.
Actually, since the IETF is a standards organization, a definition *is* needed.
And a very precise one, such that engineers can follow it and guarantee
interoperability. All known corner cases must be identified and dealt with. As
a worked example, consider this RFC:
5987 Character Set and Language Encoding for Hypertext Transfer Protocol
(HTTP) Header Field Parameters. J. Reschke. August 2010. (Format:
TXT=20108 bytes) (Obsoleted by RFC8187) (Status: HISTORIC) (DOI:
10.17487/RFC5987)
https://tools.ietf.org/html/rfc5987
10 pages specifying in high detail *exactly* how to do one very small part of
HTTP handling: encode non-ASCII data into HTTP headers.
You're going to need to explain your "WWW brain" in equally detailed syntax and
semantics, not just handwaving. What the browser does when a user enters
'httpi://', what it sends to a server, how the server responds, including all
the possible error codes, and how the user's browser should react to the
various errors.
I'll provide a hint: You may want to learn enough about HTTP so you realize that
most extension to the base HTTP/1.1 specification are done as additional header
fields rather than a new httpX:// protocol. (For example, there's a very specific
on-the-network protocol issue why we even have an https:// at all
And learn enough about browser design to figure out how to Make It Just Work
for a user without having to specify httpi:// (which will be important for
things like search engines or embedded links - otherwise a user will have to do
a "copy URL to clipboard", then paste it into the URL bar, and add an 'i' to
the http. And do it every link they want this new feature on)
But, of course, first you need to explain your idea in sufficient detail that makes
it clear that the IETF should work on it. The fact that it's already being done
all over the place without your idea means you'll need some very good reasons
indeed....
> I as a WIndows Personal computer android user have supported the companies
> that manufacture and market them so i have a right to demand that they ship
You can *request* they do so. You're not in a position to *demand* it. I'm not
in a position to demand it, either. Neither is the IETF - it merely
standardizes the "if you're going to do it, it should be done this exact way".
Think of it as traffic laws for the Internet, standardizing the design of cars
and trucks and traffic signs.
> efficient solutions and httpi is more efficient than browser extensions.
Show actual proof that it's more efficient. Include network traces, round trip
times, network utilization statistics, and other relevant data. Handle
latency, bandwidth needed at the server end, and bandwidth needed at the client
end. Make sure you cover all the common cases: non-overlapped requests,
multiple overlapped requests to multiple servers, and multiple overlapped
requests over one connection to one server.
Note that this can be difficult - for instance, https://www.cnn.com makes
references to *at least* 31 different servers. And that's not counting all the
references stopped by my ad-blocker - without that, there would undoubtedly
be many more than just 31.
> Does IETF enforce any such, then they have to enforce this implementation and
> all httpd services tunnel through httpi.
Remember what I said about error codes? This is a good example. What happens
if you send httpi:// to a server running older software that doesn't support it
(which at the present time means "every single one out there")? This means you
need to worry about things like versioning and forward and backward
compatability. And again - you have to be *specific* as to what error the
server sends, and what the browser does in response, so that a software
engineer implementing this for Edge or Chrome is able to make it work based on
the specification.
Feel free to come back when you've gotten it to a state that the IETF can use.
Attachment:
pgpC9DyGIixwY.pgp
Description: PGP signature
