David Conrad wrote:
> What is this code trying to do?
The code you quoted returns the number of domain labels, counting from
the right hand end, which are used to make up the "domain" property
(e.g. 2). The code works this way because those are the terms in which
the algorithm was described to me.
msg06185.html
#!/usr/bin/perl -w
# Implementation of the IE algorithm for determining the IURI 'domain'
# property from a FQDN. This property is important in determining the
# behaviour of IE 8's address bar highlighting.
#
# Written by Gervase Markham <[EMAIL PROTECTED]>
# 2
Ted Lemon wrote:
> On Jun 11, 2008, at 6:26 AM, Gervase Markham wrote:
>> It's not true that we won't work on any other solution. This is what we
>> have now, and there have been no alternative proposals which (to my
>> mind) look like producing anything workable
Antoin Verschuren wrote:
>> No. I don't need to sell you the idea. The idea doesn't stand or
>> fall on the opinion of this mailing list.
>
> Did you really say this ? Did I read this correctly ?
>
> No, can't be. I don't think Mozilla wants to insult all the IETF
> experts that have voluntarily
Joe Baptista wrote:
> Listening would you mind explaining something here. Do we work for
> you? I'm pretty sure your being paid to promote your public suffix idea
> but we are not. There are many here who are too busy to spend time
> reading your stuff, let alone go back to the web site for upda
Joe Baptista wrote:
> Listening would you mind explaining something here. Do we work for
> you? I'm pretty sure your being paid to promote your public suffix idea
> but we are not. There are many here who are too busy to spend time
> reading your stuff, let alone go back to the web site for upda
[EMAIL PROTECTED] wrote:
> that URL does not resolve in the way you might
> expect.
Sorry :-) Cut and pasted from my browser without checking. That's my
local testing copy, of course.
http://www.publicsuffix.org/learn/
Gerv
___
DNSOP mailin
Edward Lewis wrote:
> Is the issue that a cookie needs to state for what domains it is
> valid?
No.
> Are you trying to relate domain names to a registrant?
No.
I must confess it is somewhat frustrating when, having put up a website
explaining what this is all about, and having had a long d
Joe Baptista wrote:
> I asked you a question earlier in this conversation but have yet to get
> a response. So I will ask it again.
You asked me by private mail, and I replied in private at 10/06/08 10:47
my time.
> What happens if a TLD is not on the Public Suffix list?
The same thing as now.
Jeroen Massar wrote:
> If adserver.co.uk (as they are 'evil') sets a cookie for co.uk then
> indeed that cookie gets sent to mybank.co.uk too. What harm does/can
> this do? (Except that they might set a cookie identical of type to the
> bank one and maybe auto-login to their bank account!?)
Say
Jamie Lokier wrote:
> Oh? How is this reconciled with earlier comments that
> login.mybank.co.uk and accounts.mybank.co.uk are grouped together - or
> is the Public Suffix List only for history grouping in browsers, not
> for cookie sharing?
I'm not sure that either dnsop or ietf-http-wg are inte
Wes Hardaker wrote:
> * We, mozilla, obviously can't do this ourselves
On the contrary. We have done it for ourselves.
> so you must do it for
> us or else negative things will happen (and you'll be at fault, not
> us, mozilla). Please continue to do this work for us till the end of
> ti
Wes Hardaker wrote:
> * We, mozilla, obviously can't do this ourselves
On the contrary. We have done it for ourselves.
> so you must do it for
> us or else negative things will happen (and you'll be at fault, not
> us, mozilla). Please continue to do this work for us till the end of
> ti
Florian Weimer wrote:
> Have a look at this file:
>
> /usr/share/apps/khtml/domain_info
Indeed. It looks like they do the same thing as us, but in a far more
approximate and erroneous fashion.
Persuading them to use the public suffix list would be an improvement.
Gerv
__
Dean Anderson wrote:
>> That's unfortunate; but I must say this upset was not communicated to me.
>
> Probably that's because you are using SORBS to filter your email. SORBS
> has an unusually high number of false positives, and for example,
> falsely claims that that 130.105/16 and 198.3.136/21 a
Paul Hoffman wrote:
> For your IDN display technology, Mozilla decides which TLDs have a
> "responsible attitude". Mozilla enforces these rules as a "powerful
> incentive" for TLDs to do as Mozilla wishes.
As are Microsoft's rules - which, sadly, are both different and IMO much
more likely to ret
Henrik Nordstrom wrote:
> I seriously question this "will break" part. Sure, they will get
> annoyed, but in nearly all possible solutions layering ontop of the
> existing cookie system there will be easy ways for the owners of such
> sites to make them behave well, and a transition period giving t
Doug Barton wrote:
> Gervase Markham wrote:
>> The fact that I am working on this question now is not to present a
>> /fait accompli/; I've just been too busy to get to it.
>
> Is it just me, or do those two statements seem to contradict one another?
I don't t
Jelte Jansen wrote:
> won't they run into the very same problem if only tld's (and their
> sld's) are marked as don't-set-cookies-here? Or is livejournal.com also
> supposed to get on the list of public suffixes?
No. They can set cookies for www.livejournal.com or
admin.livejournal.com (as opposed
Florian Weimer wrote:
> * Jamie Lokier:
>> (By the way, although we're talking about administrative divides in
>> the DNS tree, a little thought might be given to administrative
>> divides in URL trees. There are a fair number of sites containing
>> http://domain.com/user1/* and http://domain.com/
Jamie Lokier wrote:
> The information would be published in the ISP's TLD-alike domain, not
> the customer's subdomains. E.g. 'co.uk', not 'mybank.co.uk', assuming
> the information is "each domain $WORD.co.uk is independent".
>
> The values are the same information that you are gathering. The
>
Hi Doug,
Doug Barton wrote:
> Coming as it does late in your development cycle (and especially given
> the "enthusiastic" reaction you've received here today) the temptation
> would be for you to dig your heels in and insist on moving forward as
> planned. I urge you to resist that temptation.
Ju
Kim Davies wrote:
> This thread sounds remarkably like deja vu. Indeed, the TLD community was
> rather upset a few years ago by Mozilla taking unilateral action to
> introduce a hard-coded white-list of acceptable IDN TLDs without prior
> consultation.
That's unfortunate; but I must say this upse
Paul Hoffman wrote:
> One possible method is to start Firefox 3.0 with an empty registry, and
> fetch a registry update from Mozilla each time a user does either a
> manual or automatic "check for updates" on Firefox.
That's an interesting idea. We didn't make the data remotely-updatable
on its o
Stephane Bortzmeyer wrote:
> * Difficulty of managing this list (and even worse if every browser
> vendor ask the TLD managers for a slightly different info)
We are making our data available for everyone to use, so we are trying
hard to make sure this doesn't happen.
> * Administrative boundari
David Conrad wrote:
> You're talking about essentially creating a registry of their registry
> policies and distributing it statically via your product. I would
> imagine they might be interested and might even have some useful input
> to provide.
We're about to ask them for their input.
> Just
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
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
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
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
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
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 (
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
the list, and details for sending updates is at:
http://publicsuffix.org/submit/
We also ask you to send updated information whenever you change your
registration policies in a way which affects the list.
Thanking you in advance,
Gervase Markham
___
DNSOP m
37 matches
Mail list logo
