On Thu, 06 Nov 2008 21:51:24 +0100, Dean Anderson <[EMAIL PROTECTED]> wrote:
The domain structure of a TLD is not something that changes frequently,
it
is therefore suitable for a static file that contain the necessary
information, something which will also reduce network traffic.
This static file is a bad idea waiting to not happen. Root servers
Just assure you: By "static" I do not mean a file that won't change for
the next 100 years. I mean "static" in the web service sense, as opposed
to "dynamic" script generated content.
My suggestion in earlier versions of the draft have been that the client
caches the received file for 30 days, then revalidate it, and that new
registry-like domains should be included 90 days before going active.
This type of information is not updated frequently enough that a dynamic
check for every domain is needed, nor is the number of domains a sizeable
fraction of the domains registered, but small enough to make for a
relatively small download every month or two. Nor is it likely to happen
often (if ever) that a registry-like domain changes to an ordinary domain;
it is more likely to be the other way around.
I agree that the idea about figuring out tld substructure in order to
determine cookie administration is also fatally flawed, for the reasons
Well, as I've mentioned earlier, cookies is the area that have spurred my
development of this specification. It is not the only area asking for such
information, as I've also mentioned earlier, for example URL display in
FF3 and IE8, and if I am not mistaken, Google Chrome. And there are likely
more.
One area where developers want to use such information is to help users
understand where they actually are on the Internet, for example when being
directed somehow to
"www.my-trusted-bank.com.foo.bar.and.something.else.malicious.example.net",
by highlighting "malicious.example.net", and making the rest almost
invisible.
already described: There is no way to determine administrative control
via DNS queries. Either case of same SOA or different SOA could mean
same admin control or different admin control.
Better suggestions for discovering and/or adding the information we need,
or better ways to solve the problems we are working on, will be welcomed.
In order to limit access to cookies to its admin control, you need to
change the cookie format, and probably encrypt the cookie data, and make
changes to the HTTP protocol to make it clear what admin authority
sourced the date, is requesting the data, and to what admin authorities
the data can be provided. It is impossible to infer this information
from the information now available to the browser. Protocol and format
changes are required. DNS is the wrong place to look.
As mentioned earlier in this thread, I am also promoting an updated cookie
specification. However, that is going to take a while to implement when
the draft eventually have become an RFC.
However, what has helped cookies get to the marketcoverage they do have
(just about every web site serving anything more advanced than static HTML
files) is their ease of use. Write a spec that make them any more complex
to use, and the spec will not get implemented, much less adopted by the
market. My draft may actually be close to that edge because it requires
the host to set the cookie for a subdomain in which the host's name is the
suffix, making website deployment more difficult in some respects.
But, as mentioned, cookies is not the only area wanting this information.
Not anymore.
So: Treat cookies as a usage example (it is included as a profile example
in the draft; BTW I did consider, but decided against, releasing those two
parts as separate documents), not the sole reason for the subtld draft's
existence.
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: [EMAIL PROTECTED]
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
