On Sat, 21 Jul 2018 07:13:42 -0600, pradeep@xxxxxxxxxxxxxxxxx said: > What i proposed is when user types httpi://www.pradeepkumarxplorer.com > the information served by pradeepkumarxplorer.com httpd tunnels > through another > httpi that could be any solution server side scripting that shows the > viewer of the information with additional links suggested by the WWW > Brain. 1) No definition of "WWW Brain". 2) If anything, the Web is already *full* of "You may also like..." links added by the server side. Quite obviously: 2a) they don't need an httpi:// to insert them 2b) they aren't very expensive to insert 2c) There's browser extensions to *remove* these 3) Therefor, the proper place for adding "additional links" is obviously at the user browser end - and there's extensions that will do this sort of thing without need of an 'httpi://' protocol definition If these additional hyperlinks are something that's to be under user control, it's a matter for the browser creators to add a configuration options or way for an extension to interact and do the searching. And that will be different for Chrome, or Firefox, or Edge, or a MacOS or iOS browser and thus not an IETF issue. For a worked example: https://chrome.google.com/webstore/detail/highlight-to-search/floipahigmmkfhkoapmnijnlnboniglg?hl=en Highlight the text on the page, and it will go a Google search for more info. No httpi:// needed. You'll have to explain what problem you're trying to solve that isn't already solved. In addition, you need to explain why a new on-the-network protocol (which is what the IETF does) is needed, when it's already been demonstrated to be doable without any new protocols or anything else that is done by the IETF. > This saves thousands of hours and possibly millions of dollars for > website Creators from manually hypertexting their files using whatever > tools like Hypothesiser or many browser extensions available. Not really. A site that insists on adding their own links will still add their own links, no matter what the user signals. Remember - if your "www brain" extension is able to find keywords in the page and add additional links, the web server can *also* do the same thing without an httpi:// - and so can the user's browser (and probably better, because the user's browser can query a site like Google that can make better suggestions because it knows what previous queries the user has done...) > WHat i proposed in my second draft is a switch on the server side that > prevents an unauthenticated user from seeing any information and > authentication means First off, if it's a switch on the server side, it's a server configuration issue, not an IETF issue. The way to specify that switch, and how it works, will be different for Apache, or ngnix, or IIS, or Squid, or anything else that is functioning as a web server or proxy. And the user *SHOULD NOT* (in the RFC sense) be specifying information to override the server's decision. Again - there's absolutely nothing stopping the server from doing whatever sort of authentication it wants to, and there's no need for IETF action. Webservers can already do sufficient authentication - and a case can be made that it's not the IETF's job to specify that authentication. The short summary - you're not going to get an IETF list to discuss either draft until such time as you show that it's something that is an IETF issue to deal with. And given that both drafts address things that have already been done without any IETF action, it's unlikely you'll be able to show that the IETF needs to do anything. > but someone from ietf.org has deleted my email pradeep@xxxxxxxxxxxxxxxxx and >i had to use my other email pradeepan88@xxxxxxxxxxx. There's no way to say in > internet that pradeep@xxxxxxxxxxxxxxxxx and pradeepan88@xxxxxxxxxxx are the > same individual thats me 1) The deletion may be a hint that somebody at the IETF doesn't want to hear from you because your mails aren't related to the IETF. 2) The fact that you can't tell the internet that two email addresses are the same person is a good example of why your 'userinfo' proposal isn't workable. (Plus, it's not even a fixed relationship - I have multiple email addresses, and I have some sites that I have told that (for example) 3 of the 5 addresses are actually the same person - but there's other sites that I do *NOT* want then deciding that address A and B and C are the same person. There's no way for a 'userinfo' service to securely get that right.
Attachment:
pgpsPAo3YbWA3.pgp
Description: PGP signature
