At 3:02 PM -0700 6/9/08, Doug Barton wrote:
>I'm also not sure you quite understand the magnitude of the task you're
>undertaking. It's a matter of fact that any sentence including the
>phrase "all TLDs" is doomed from the start. :) You're dealing with a
>wide variety of business models (often wit
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Yngve and Gerv,
As you have no doubt concluded by now, you've touched a nerve. :) It
doesn't seem to me that you have, but I hope that you will not interpret
the strong reaction you've received as an attack. It's simply the case
that what you're
I'm a little puzzled by this discussion. Why not just set up a list
of TLDs in a mozilla.org subdomain, sign the subdomain with DNSSEC,
put the DNSSEC public key into firefox, and have firefox consult the
TLD list in the DNS, verified with DNSSEC, whenever information is
needed?
That way
On Mon, Jun 09, 2008 at 04:53:42PM +0100, Gervase Markham wrote:
> > What you're really
> > trying to do here is extract meaning from the domain name, but you
> > can't do that reliably. Previous efforts in that direction have
> > failed in unexpected ways; and given that you seem to have multipl
On Mon, Jun 09, 2008 at 11:07:23PM +0200,
Phil Regnauld <[EMAIL PROTECTED]> wrote
a message of 21 lines which said:
> about:config in firefox
>
> search for IDN
>
> disable network.IDN.whitelist for all listed TLDs.
Andrew was asking how to disable the "cookie domain policy
On Mon, Jun 09, 2008 at 03:21:11PM +0100,
Gervase Markham <[EMAIL PROTECTED]> wrote
a message of 22 lines which said:
> I am not particularly interested in a long discussion about whether
> we need this data. Please be assured that we need it.
That's a very good summary of Mozilla's method. "T
Stephane Bortzmeyer (bortzmeyer) writes:
> On Mon, Jun 09, 2008 at 10:29:27AM -0400,
> Andrew Sullivan <[EMAIL PROTECTED]> wrote
> a message of 52 lines which said:
>
> > Is there any way to turn this off in Firefox 3?
>
> Switch to a free software browser without this very bad policy?
>
> ht
On 9 Jun 2008, at 12:57, Brian Dickson wrote:
> Gervase Markham wrote:
>> We've had this basic problem in the domain of cookies for years. I
>> don't
>> expect another solution to pop out of the woodwork now. But I'm
>> open to
>> being surprised :-)
>>
> Surprise!
>
> If you want grouping, t
On Mon, Jun 09, 2008 at 10:29:27AM -0400,
Andrew Sullivan <[EMAIL PROTECTED]> wrote
a message of 52 lines which said:
> Is there any way to turn this off in Firefox 3?
Switch to a free software browser without this very bad policy?
http://www.konqueror.org/
___
On Mon, Jun 09, 2008 at 11:56:05AM -0700,
David Conrad <[EMAIL PROTECTED]> wrote
a message of 46 lines which said:
> Some might even think it rude (even Microsoftian :-)) not to ask.
Me, for instance. And, AFAIK, Microsoft did not announce such a scheme
for Internet Explorer. This is a sad day
On Mon, Jun 09, 2008 at 12:57:00PM -0400,
Brian Dickson <[EMAIL PROTECTED]> wrote
a message of 48 lines which said:
> If you want grouping, there is a simple-to-code, reliable, and
> authoritative way to do so.
>
> Zone cuts (in DNS).
I find the arm-twisting by Mozilla very questionable but
At 3:21 PM +0100 6/9/08, Gervase Markham wrote:
>I am not particularly interested in a long discussion about whether we
>need this data. Please be assured that we need it. I am, on the other
>hand, open to suggestions about better ways to obtain it.
One possible method is to start Firefox 3.0 with
On 9/06/08 11:56 AM, "David Conrad" <[EMAIL PROTECTED]> wrote:
>
> On Jun 9, 2008, at 9:34 AM, Gervase Markham wrote:
>>> I'm curious: have you consulted with the various TLD-related
>>> organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD,
>>> etc.) on
>>> how to solve this problem?
>>
>>
Gervase,
On Jun 9, 2008, at 9:34 AM, Gervase Markham wrote:
>> I'm curious: have you consulted with the various TLD-related
>> organizations (e.g., ccNSO, gNSO, CENTR, APTLD, AfTLD, LACTLD,
>> etc.) on
>> how to solve this problem?
>
> No. What do you think they'd say that hasn't been said in th
Gervase,
I'm going to piggy-back this on something Edward Lewis wrote:
> ...
> I doubt that you'll find any repository that can
> be used to register "registry-like" zones. The
> DNS lacks anything like a RADB, RPSL, etc.,
> mechanism employed by the routing infrastructure.
> Partly because,
The frivolous, dishonest, and false statements in the January 15, 2008
IESG Appeal Response found at
[http://www.ietf.org/IESG/APPEALS/appeal-response-dean-anderson-01-15-2008.txt]
must be corrected. Persons are begining to incorrectly claim that the
IETF has no members, and no ability to make of
Gervase,
The Dan Jay (and later) cookie policy drafts had a dsig in the payload
so that the data collection policy (DCP) asserted in a cookie could be
verified. The xml dsig draft wasn't ready, so we took off that part of
the payload, leaving only the DCP. At the W3C P3P Spec WG meeting in San
Gervase,
first I'd like to thank Yngve for providing the pointer and you for following
his advice.
> I am not particularly interested in a long discussion about whether we
> need this data. Please be assured that we need it. I am, on the other
> hand, open to suggestions about better ways to obta
Gervase Markham wrote:
> We've had this basic problem in the domain of cookies for years. I don't
> expect another solution to pop out of the woodwork now. But I'm open to
> being surprised :-)
>
Surprise!
If you want grouping, there is a simple-to-code, reliable, and
authoritative way to do
Jamie Lokier wrote:
> Gervase Markham wrote:
>>> Wouldn't it be more appropriate for MyBank to _itself_ say the history
>>> for these sites should be grouped? E.g. in an HTTP response header,
>>> or DNS record for mybank.co.uk?
>> The total amount of effort required for this solution is mind-boggl
Gervase Markham wrote:
> > Wouldn't it be more appropriate for MyBank to _itself_ say the history
> > for these sites should be grouped? E.g. in an HTTP response header,
> > or DNS record for mybank.co.uk?
>
> The total amount of effort required for this solution is mind-boggling.
How is it more
Gervase Markham wrote:
> This isn't just about cookies. For example, we would like to group
> together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
> history. Grouping together all sites in ".co.uk" does not provide for an
> optimum user experience.
Wouldn't it be more appropriate fo
David Conrad wrote:
> I suspect I might have a better list than you (:-) hint: I work at ICANN).
Well, OK :-)
> My reading of Yngve's draft (in particular, section 5.1) led me to
> believe that all TLDs would not need to run such a service, rather that
> such a service be available in a "well kno
Jamie Lokier wrote:
> Wouldn't it be more appropriate for MyBank to _itself_ say the history
> for these sites should be grouped? E.g. in an HTTP response header,
> or DNS record for mybank.co.uk?
The total amount of effort required for this solution is mind-boggling.
> Also, wouldn't DNS genera
Gervase,
On Jun 9, 2008, at 8:57 AM, Gervase Markham wrote:
> David Conrad wrote:
>>> however, my view is that getting comprehensive buy-in
>>> would take quite a lot more time and effort than this method.
>> is the common excuse that results in lots of broken crap on the
>> Internet. It is sad t
David Conrad wrote:
>> however, my view is that getting comprehensive buy-in
>> would take quite a lot more time and effort than this method.
>
> is the common excuse that results in lots of broken crap on the
> Internet. It is sad to see the same mistake repeated again and again.
Prove me wrong
Andrew Sullivan wrote:
> Because what you are proposing to do adds special meaning to certain
> labels (and their relative position) and not to others, in exactly the
> way that previously people had special interpretations of certain
> labels and their positions in the set of labels.
Right. But
Gervase,
On Jun 9, 2008, at 4:48 AM, Gervase Markham wrote:
> Fortunately, Firefox has an extremely good and fast update and uptake
> rate. This is partly because we don't give users a choice about taking
> non-major-version updates.
And how does this update/update rate take into account folks wh
On Mon, Jun 09, 2008 at 03:43:29PM +0100, Gervase Markham wrote:
> > RFC 3696 explains, I think, most of the reasoning that I would offer
> > for why I think this is a bad idea. I urge you and others who are
> > planning to ship this kind of feature to go (re)read that RFC.
>
> Why do you think
Andrew Sullivan wrote:
> Is there any way to turn this off in Firefox 3?
Not that I know of.
> RFC 3696 explains, I think, most of the reasoning that I would offer
> for why I think this is a bad idea. I urge you and others who are
> planning to ship this kind of feature to go (re)read that RF
On Mon, 09 Jun 2008 16:07:10 +0200, Wes Hardaker <[EMAIL PROTECTED]>
wrote:
> EG, if I had "www.example.com" and I received cookies in a request from
> "example.com", "images.example.com" and "hacker.com" I could determine
Not sure if you mean that www.example.com is sending cookies for
examp
On Mon, Jun 09, 2008 at 11:00:39AM +0100, Gervase Markham wrote:
> The following email message will shortly be sent to the technical
> contact for all TLDs. Yngve Pettersen at Opera suggested that I also let
> you both know about it.
>
> The technology in question, including a version of the list
Patrik Fältström wrote:
> What about new structures in a TLD that is in the list?
If the structure is additive, then again there is no problem. If it is
reductive, then there are potential problems depending on how the
customers of the newly-available domains set things up.
Let us say, for exampl
Wes Hardaker wrote:
> I think a better policy would be to fix the HTTP protocol so that it
> could specify an incoming cookie policy. Rather than having every site
> under the sun be able to set cookies and block that by some random list
> of hard coded "within" list, allow each site to specify wh
At 16:00 +0200 6/9/08, Yngve Nysaeter Pettersen wrote:
>On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <[EMAIL PROTECTED]>
>wrote:
>
>> The problem with any such mechanisms is that the barrier of entry for
>> new players (that does not match the currently used list -- including
>> non-upgr
> On Mon, 09 Jun 2008 12:48:19 +0100, Gervase Markham <[EMAIL PROTECTED]>
> said:
GM> Fortunately, Firefox has an extremely good and fast update and uptake
GM> rate. This is partly because we don't give users a choice about taking
GM> non-major-version updates.
And how long to do you mai
On Mon, 09 Jun 2008 15:32:11 +0200, Patrik Fältström <[EMAIL PROTECTED]>
wrote:
> The problem with any such mechanisms is that the barrier of entry for
> new players (that does not match the currently used list -- including
> non-upgraded software) is increased. More than what people think.
Tha
On 9 jun 2008, at 15.41, Gervase Markham wrote:
> Patrik Fältström wrote:
>> The problem with any such mechanisms is that the barrier of entry for
>> new players (that does not match the currently used list -- including
>> non-upgraded software) is increased. More than what people think.
>
> This
Patrik Fältström wrote:
> The problem with any such mechanisms is that the barrier of entry for
> new players (that does not match the currently used list -- including
> non-upgraded software) is increased. More than what people think.
This isn't so. For TLDs not in the list, the usual rules (
On 9 jun 2008, at 12.00, Gervase Markham wrote:
> The following email message will shortly be sent to the technical
> contact for all TLDs. Yngve Pettersen at Opera suggested that I also
> let
> you both know about it.
The problem with any such mechanisms is that the barrier of entry for
new
On Mon, Jun 09, 2008 at 08:33:30AM -0400, Edward Lewis wrote:
> If the browsers do implement a check based on TLD name, I bet they
> are also gullible enough to implement RFC 3514.
Browsers already implement a lot of 'supra-dns' knowledge. Try visiting a
known malware or phishing site these days
On Mon, Jun 09, 2008 at 02:24:30PM +0200, Antoin Verschuren wrote:
> > You can't hijack something that does not exist though, which is what I
> > think
> > is the problem here.
>
> Agree, but when this global list of local DNS policy would exist and used,
> which would be authoritative, the list
(Responding only on the DNS list to avoid cross posting.)
At 14:11 +0200 6/9/08, bert hubert wrote:
>On Mon, Jun 09, 2008 at 02:02:05PM +0200, Antoin Verschuren wrote:
>(...)
>> I'm very afraid that Mozilla is trying to hijack the authority model here.
>
>You can't hijack something that does not
Re Antoin,
[EMAIL PROTECTED] (Antoin Verschuren) wrote:
> > You can't hijack something that does not exist though, which is what I
> > think
> > is the problem here.
>
> Agree, but when this global list of local DNS policy would exist and used,
> which would be authoritative, the list or the DN
> -Original Message-
> From: bert hubert [mailto:[EMAIL PROTECTED]
>
> You can't hijack something that does not exist though, which is what I
> think
> is the problem here.
Agree, but when this global list of local DNS policy would exist and used,
which would be authoritative, the list o
On Mon, Jun 09, 2008 at 02:02:05PM +0200, Antoin Verschuren wrote:
(...)
> I'm very afraid that Mozilla is trying to hijack the authority model here.
You can't hijack something that does not exist though, which is what I think
is the problem here.
Bert
--
http://www.PowerDNS.com O
> If you are going to push this 'technology', you might want to consider
> doing an SPF-alike test, thus getting that information from the provider
> of the label, or better: fix the cookie standards.
I must agree here.
What I see here is an attempt to make a global list of local policy.
That won'
Jeroen Massar wrote:
> [Why not go DNSSEC first instead of solving a problem which is not a
> real problem? See below... ]
I'm not sure that DNSSEC solves the problem we are trying to solve, but
would be happy to be enlightened.
> You are *hard-coding* such a list into a 'product'? You do realize
[Why not go DNSSEC first instead of solving a problem which is not a
real problem? See below... ]
Gervase Markham wrote:
[..]
> The technology in question, including a version of the list, is about
> to ship in Firefox 3, but we'd like to verify and improve the quality
> of the underlying data.
Dear HTTP and DNS Operations WGs,
The following email message will shortly be sent to the technical
contact for all TLDs. Yngve Pettersen at Opera suggested that I also let
you both know about it.
The technology in question, including a version of the list, is about to
ship in Firefox 3, but we'd
50 matches
Mail list logo
