Re: [Ietf] New .mobi, .xxx, ... TLDs?
Hi. While this discussion on the IETF list has been very interesting, it is probably worth noting that the odds of ICANN staff following the IETF list to the extent needed to pull out this thread and make use of it are not high. Instructions for making comments that they, and presumably the evaluators, will see are at http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.htm That page contains both addresses for making general comments and addresses for specific comments on each proposal, along with pointers to archives of comments made so far. The comment period on the specific applications and forms closes on 30 April (see http://www.icann.org/tlds/new-stld-rfp/new-stld-application-parta-15dec03.htm ). If those of you who have been carrying on this debate want even a chance that your positions will be carefully considered, I suggest going over to ICANN's site and posting appropriate summaries. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Thu, Apr 29, 2004 05:12:07PM +0300, Aki Niemi allegedly wrote: I find it hard to interpret that text in any other fashion -- they want to describe end-to-end protocols by DNS name. I don't quite see what the difference here is to .edu for example. Isn't this indeed very similar to how the .edu provides a clearly recognisable label for educational services and content? .edu was an administrative distinction. (So was .net, originally.) The intent here is clearly to distinguish the *use* of the name, not the administration. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
So what is the rationale for organizing ourselves based on our respective countries? to match legal jurisdictions Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Fri, Apr 30, 2004 at 04:47:17AM -0400, Scott W Brim wrote: I don't quite see what the difference here is to .edu for example. Isn't this indeed very similar to how the .edu provides a clearly recognisable label for educational services and content? .edu was an administrative distinction. (So was .net, originally.) The intent here is clearly to distinguish the *use* of the name, not the administration. The .edu is a (perpetuated) anachronism like .com. You could ask the US universities to rename to .ac.us tree - good luck! :) It's interesting how some countries sub-delegate (like the UK, to .co.uk, .ac.uk, .gov.uk, .ltd.uk, .org.uk, etc) and others do not. Doing so allows some more headroom in namespace, but not all such sub-delegations are exactly policed for validity. tim ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
At 03:42 30/04/04, John C Klensin wrote: http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.htm Dear John, it seems that (one of the) most important entry (the letter from ITU regarding the .tel/.mobi requests) cannot be accessed. http://forum.icann.org/lists/stld-rfp-general/msg00043.html This seems to be a singular impeachment to a transparent debate on the matter. Due to the delay I suggest that ITU sends IETF a copy while you might as a BoD Member ask staff to urgently correct that situation. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
jfcm wrote: At 03:42 30/04/04, John C Klensin wrote: http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.htm Dear John, it seems that (one of the) most important entry (the letter from ITU regarding the .tel/.mobi requests) cannot be accessed. http://forum.icann.org/lists/stld-rfp-general/msg00043.html This seems to be a singular impeachment to a transparent debate on the matter. Due to the delay I suggest that ITU sends IETF a copy while you might as a BoD Member ask staff to urgently correct that situation. jfc It seems to be working fine by me with a little tweaking. If you download the file in the message (http://forum.icann.org/lists/stld-rfp-general/bin4.bin), and rename it to .pdf (under Windows), it opens just fine. I attached a copy of it to this message. Yakov -- Yakov Shafranovich / asrg at shaftek.org SolidMatrix Technologies, Inc. / research at solidmatrix.com Some lies are easier to believe than the truth (Dune) bin4.pdf Description:
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Jefsey (and others), Due to prompt action on the part of ICANN staff once this was called to their attention, the problem is now fixed and, due to some spam-cleaning done at the same time, the posting is now at http://forum.icann.org/lists/stld-rfp-general/msg00039.html/. The implication of your posting that this might have been deliberate (at least as I read singular impeachment) does not appear to me to be justified by anything I have seen. Instead, I suspect that the problem results from sloppy or incorrect implementations of the standards: software that relies on content-type information (in either email or HTTP) would presumably have no trouble opening the original message attachment. Software that relies, instead, on file type suffixes or other sometimes-random information, as much Windows-based software appears to do, can get itself and the user rather throughly confused. It is hard to realistically blame that problem on some malice or conspiracy at ICANN (or the ITU, or anywhere else in that set of processes). People will have to decide for themselves how most important this entry is. Personally, I found it a bit circuitous, asking for discussion (clearly a good idea) rather than really taking a position. I was, however, pleased to see the ITU Secretary General recognizing IETF's role in ENUM... that part of the story has sometimes gotten lost. And, contrary to your note, the posted note appears to comment directly only on one of the two TEL. proposals and not at all on the MOBI. one. Whether one can impute a conspiracy to that, or whether the ITU really only sees a significant problem with that one proposal, is something you would have to address with them. regards, john --On Friday, 30 April, 2004 18:36 +0200 jfcm [EMAIL PROTECTED] wrote: At 03:42 30/04/04, John C Klensin wrote: http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comme nts.htm Dear John, it seems that (one of the) most important entry (the letter from ITU regarding the .tel/.mobi requests) cannot be accessed. http://forum.icann.org/lists/stld-rfp-general/msg00043.html This seems to be a singular impeachment to a transparent debate on the matter. Due to the delay I suggest that ITU sends IETF a copy while you might as a BoD Member ask staff to urgently correct that situation. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
At 21:04 30/04/04, John C Klensin wrote: Jefsey (and others), Due to prompt action on the part of ICANN staff once this was called to their attention, the problem is now fixed and, due to some spam-cleaning done at the same time, the posting is now at http://forum.icann.org/lists/stld-rfp-general/msg00039.html/. Dear John Thank you for that. The implication of your posting that this might have been deliberate (at least as I read singular impeachment) does not appear to me to be justified by anything I have seen. I only meant (I just checked it in dictionary) deviating from the usual or expected; odd. See Synonyms at strange. But it is good you understood it your way, got the problem fixed and have now your response in the records. This will not be implied further on. It is hard to realistically blame that problem on some malice or conspiracy at ICANN (or the ITU, or anywhere else in that set of processes). True. That possible future blame is now defused ... except that now I just loop back in the mail without getting the attachment :-) May be only because of my PC? People will have to decide for themselves how most important this entry is. Personally, I found it a bit circuitous, asking for discussion (clearly a good idea) rather than really taking a position. I was, however, pleased to see the ITU Secretary General recognizing IETF's role in ENUM... that part of the story has sometimes gotten lost. And, contrary to your note, the posted note appears to comment directly only on one of the two TEL. proposals and not at all on the MOBI. one. Whether one can impute a conspiracy to that, or whether the ITU really only sees a significant problem with that one proposal, is something you would have to address with them. Please understand you are at advantage: you were able to read the document. I was not. Robert's mail says Applications (plural). As you know in intelligence 80% is the fact there was an exchange, and 20% the content. - the fact there is a letter is important (personal readings are less) - the fact you speak of conspiracy is important (even if I don't understand about what/by who it could be). It means the matter is touchy. Let build on that. There is a need to talk says Robert Shaw. Good point: you accept to talk. Maybe will you recall that they asked the same in 2000? I read positively what you say they said: (a) it means there is a dialog (b) this means they do not take position and respect the Internet autonomy (c) their 2000's position lead to ENUM. This ICANN / ITU / IETF way was positive last time. Why not this time, too? (BTW, IMHO ITU is no more at ease than ICANN with the current post-WSIS global situation ). All what I fear is that under such circumstances and pressures, someone takes a wrong decision he would not have taken otherwise. No one wants to harm the DNS and endanger a key thing which works. We all agree with that. But a debate is open on propositions which may harm the DNS. This debate was open by ICANN, so it rises questions. Basically, why is this debate about transport protocol being described in the TLD instead of being described in the scheme, happening now? It should have been prevented by the wording of the call for propositions or by an ICANN document, proposed and discussed by the GNSO, reviewed on technical parts by IETF. It should have described what is the DNS semantic and what is expected from propositions etc. If I refer myself to ICP-3, I tend to think ICANN failed its own precaution criteria for testing, yet here we are not testing. Actually, I am surprised we have a second TLD round, while the work on the evaluation report on the first round is not even started. Why that? Is there some pressure on ICANN or is it ICANN putting some pressure? In both cases one can nurture some concerns. I have no bad idea about ICANN, but I see that .mobi, .tel and .mail would be catastrophes for a global DNS, not to speak of political consequences which are not our concern here. I also see that ICANN still has today the capacity to hurt the DNS in accepting them. What I want is that this technical major threat on the global internet stability is removed. And that this kind of matter is handled by a world consensus where IETF may have its say.as well as ITU on behalf of Govs, Consumers organizations and Lingual organizations like the one we created (Eurolinc) with Louis Pouzin, J-L Grange etc. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
In message [EMAIL PROTECTED], Dean Ande rson writes: On Mon, 26 Apr 2004, Stephen Sprunk wrote: You're confusing URI methods, protocols, and TLDs disastrously. I think it is you who is reading too much into the .tel and .mobi TLD. These are not proposals to put URI method functionality into domain names, Sure there are. Here's a direct quote from the .mobi proposal: Businesses and consumers that utilise mobile devices will be able to take advantage of a wide range of Internet services and content under the mTLD that have been specifically tailored for access and use by mobile devices. The sponsored TLD provides a clearly recognisable mobile label to the services and content, indicating that they will be easy and convenient to use with mobile devices. By choice of suitable mobile-specific technologies, the service offering can be adapted to mobile-specific characteristics, such as the limitations of mobile networks and devices (throughput, temporary signal loss, etc), which will result in a better user experience for those services. I find it hard to interpret that text in any other fashion -- they want to describe end-to-end protocols by DNS name. There are two proposals for .tel; here's text from one of them: Sub-domains of .tel may not be arbitrarily defined; rather they are defined in accordance with the ITU E.164 standard. A valid e164 domain name under the .tel TLD is defined as follows: Start with a telephone number: 1-212-332-1234. Remove all non-numeric characters: 12123321234. Reverse the order of the number: 43212332121. Separate by dots: 4.3.2.1.2.3.3.2.1.2.1. Add the sTLD: 4.3.2.1.2.3.3.2.1.2.1.tel. That looks like an ENUM competitor to me. (The other .tel proposal looks like a generic TLD at first reading.) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
% There are two proposals for .tel; here's text from one of them: % % Sub-domains of .tel may not be arbitrarily defined; rather % they are defined in accordance with the ITU E.164 standard. % A valid e164 domain name under the .tel TLD is defined % as follows: % % Start with a telephone number: 1-212-332-1234. % % Remove all non-numeric characters: 12123321234. % % Reverse the order of the number: 43212332121. % % Separate by dots: 4.3.2.1.2.3.3.2.1.2.1. % % Add the sTLD: 4.3.2.1.2.3.3.2.1.2.1.tel. % % That looks like an ENUM competitor to me. (The other .tel proposal % looks like a generic TLD at first reading.) Those who do not learn from history are doomed to repeat it. This is -exactly- the tpc.int. model, the e164.int. model, the e164.arpa. model... in a phrase... lacks traction --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Wed, 28 Apr 2004, Markus Stumpf wrote: No new TLD helps for the overcrowding, as all owners of trademarks have to and will register their name and enforce delegation of the name by law. This isn't true. No one is required by law to register their trademark as a domain name. So at best a new TLD is something like a license to print money for the registrar. Ok. What's wrong with that? If sponsoring organizations are willing to pay, they should be sold what they want. Sounds like you are against commercialization. So far, I still haven't heard a _technical_ reason against these TLD's. ** What is one thing that will break if these are granted? ** Better, what is the complete list of things that will break? --Dean ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
ext Steven M. Bellovin wrote: Sure there are. Here's a direct quote from the .mobi proposal: Businesses and consumers that utilise mobile devices will be able to take advantage of a wide range of Internet services and content under the mTLD that have been specifically tailored for access and use by mobile devices. The sponsored TLD provides a clearly recognisable mobile label to the services and content, indicating that they will be easy and convenient to use with mobile devices. By choice of suitable mobile-specific technologies, the service offering can be adapted to mobile-specific characteristics, such as the limitations of mobile networks and devices (throughput, temporary signal loss, etc), which will result in a better user experience for those services. I find it hard to interpret that text in any other fashion -- they want to describe end-to-end protocols by DNS name. I don't quite see what the difference here is to .edu for example. Isn't this indeed very similar to how the .edu provides a clearly recognisable label for educational services and content? Cheers, Aki ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: [Ietf] New .mobi, .xxx, ... TLDs?
I don't think there was any lack of capability for traction for the earlier proposals, there just wasn't a surface to grip against. The news (good or bad depending on your biases) is that the telcos have some larger roles in the Internet now a days. When it was decided to open up TLDs, one should have expected that large multi-national bodies would want to be represented at that level, and for a variety of purposes. I would not be surprised if .tel and .mobi may only be the beginning. Some could certainly argue that there should be namespace injection points into the DNS for .itu and .gsm, ... Much like established names get inserted into multiple TLDs (e.g. company_name.com, company_name.fr, company_name.net, ...), I will be surprised if we don't end up with multiple injections of the fundamental telco naming space (e.164) into the DNS. for your consideration, peterf From: [EMAIL PROTECTED] on behalf of Bill Manning Sent: Thu 4/29/2004 6:21 AM To: Steven M. Bellovin Cc: Dean Anderson; Stephen Sprunk; jfcm; Tim Chown; [EMAIL PROTECTED] Subject: Re: [Ietf] New .mobi, .xxx, ... TLDs? % There are two proposals for .tel; here's text from one of them: % % Sub-domains of .tel may not be arbitrarily defined; rather % they are defined in accordance with the ITU E.164 standard. % A valid e164 domain name under the .tel TLD is defined % as follows: % % Start with a telephone number: 1-212-332-1234. % % Remove all non-numeric characters: 12123321234. % % Reverse the order of the number: 43212332121. % % Separate by dots: 4.3.2.1.2.3.3.2.1.2.1. % % Add the sTLD: 4.3.2.1.2.3.3.2.1.2.1.tel. % % That looks like an ENUM competitor to me. (The other .tel proposal % looks like a generic TLD at first reading.) Those who do not learn from history are doomed to repeat it. This is -exactly- the tpc.int. model, the e164.int. model, the e164.arpa. model... in a phrase... lacks traction --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: [Ietf] New .mobi, .xxx, ... TLDs?
Dean Anderson wrote: On Wed, 28 Apr 2004, Markus Stumpf wrote: No new TLD helps for the overcrowding, as all owners of trademarks have to and will register their name and enforce delegation of the name by law. This isn't true. No one is required by law to register their trademark as a domain name. IANAL, but in my discussions with lawyers focused on trademark law, in effect they are required. The perception that they are not defending their rights effectively means they abandon them. So at best a new TLD is something like a license to print money for the registrar. Ok. What's wrong with that? If sponsoring organizations are willing to pay, they should be sold what they want. Sounds like you are against commercialization. So far, I still haven't heard a _technical_ reason against these TLD's. The technical argument here is flattening of the name space with the associated concentration higher up the tree. There is nothing specific about these strings, but why do they have any more rights than any other string? Why shouldn't trademark owners be able to register the name 'yourtrademarkhere.', or anyone register 'yourpersonalfavoritestring.'? Do you really think the root is the right place for all names? If not, what technical characteristic differentiates strings that should vs. not? /flame-suit-on/ Rather than granting new TLDs, there should be an effort to deprecate the existing non-cc TLDs and move everyone out within 3 years. The historical artifact of a failed experiment is no reason to continue down that path. Tony ** What is one thing that will break if these are granted? ** Better, what is the complete list of things that will break? --Dean ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Thu, Apr 29, 2004 at 06:21:20AM -0700, Bill Manning wrote: Those who do not learn from history are doomed to repeat it. This is -exactly- the tpc.int. model, the e164.int. model, the e164.arpa. model... in a phrase... lacks traction So, place your bets on which slippery slopes ICANN takes us down... I'm not convinced of a good argument for any of the proposed new TLDs to be granted. But I'm sure some/many will. More money for ICANN... This is the sort of thing ISOC should speak out on. Tim ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
This is the sort of thing ISOC should speak out on. doh! ISOC can't as they are the major benefactor from the .org divestature from verisign. sorry, try again. -rick ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On 29-apr-04, at 21:18, Tony Hain wrote: This isn't true. No one is required by law to register their trademark as a domain name. IANAL, but in my discussions with lawyers focused on trademark law, in effect they are required. The perception that they are not defending their rights effectively means they abandon them. Defending their trademark doesn't necessarily mean registering every possible domain with the trademark in it, but it does usually mean going after other people who register a domain with the trademark in it. (Although there is always the slight problem that domain names are globally unique while very few trademarks are.) So far, I still haven't heard a _technical_ reason against these TLD's. The technical argument here is flattening of the name space with the associated concentration higher up the tree. So what angle hierarchy is desirable? Obviously a completely flat space isn't good because the zones get too large, but a very deep space isn't either as it takes more time to recurse through. /flame-suit-on/ Rather than granting new TLDs, there should be an effort to deprecate the existing non-cc TLDs and move everyone out within 3 years. The historical artifact of a failed experiment is no reason to continue down that path. So what is the rationale for organizing ourselves based on our respective countries? If I may borrow your suit for a minute, I have another suggestion: no hard limits on TLDs, but every organization only gets to have a domain name in one TLD. So the practice of registering domain.* would have to end. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
So, place your bets on which slippery slopes ICANN takes us down... ICANN loves these sponsored TLDs. It's the only kind they are presently considering. Sponsors generally have the cash needed to cover ICANN's application fee (which is typically on the order of $35,000 to $50,000, and is non-refundable even if the application is turned down or left in an indefinite limbo of being neither accepted nor rejected) and any ongoing tithes. (Remember, ICANN's budget is growing towards $10,000,000USD per year and that money has to come from somewhere.) And the sponsors generally have well a behaved and limited membership and are thus less likely to burden ICANN staff with work and are less likely to get into disputes (and lawsuits) with ICANN. I personally find many of the proposed uses for these sponsored TLDs rather silly and non-innovative - and they could well be done further down the DNS hierarchy and their only reason to be at the top level is for the prestige (and image marketing value) of having top level domain status. There are a couple of things about this situation: First, is that some of the TLD proposals before ICANN, such as .mobi, might contain some seeds of technical harm to the net. For example, if the .mobi folks don't use their own intermediate caching resolvers and rather allow all those mobile devices to go directly to the roots then there could be an increase in the traffic going to root and other servers. This could be exacerbated if those devices are frequently power cycled and lose their DNS caches. The .mobi folks haven't said that they are going to do this, but then again they haven't said that they are aware of this potential issue. Second, the idea that a TLD categorizes all of the resource records of all types found under that TLD seems to me to be wrong. For instance, assume there's a TLD called blue. if an A record found under a.b.c.blue leads me to an IP address on an interface, it is unreasonable to believe that the only services delivered via that address are of a blue nature. I suspect that many people who want these TLDs think of the net only in the limited sense of the world wide web. Third is that, as Tony Hain mentioned, there is trademark pressure that will eventually suggest to every big trademark holder that they ought to be a TLD. This may or not come to pass, but we can guess that at least some of the big trademark folks will give it a try, particularly after some of ICANN's sponsored TLDs ossify over time into de facto marks and thus blaze a trail that trademark owners might want to follow. And where one trademark owner goes, the herd is sure to follow. My own view is that we ought to be trying to shape the DNS tree so that it is well shaped in terms of width and depth of the hierarchy. I don't know the metrics of that shape. Have there been studies regarding the how the efficiency of DNS and DNS caching vary with DNS label depth and zone width? As for uses of TLDs - my own view is that as long as they are allocated only rarely then the few awards should go to those uses that contain the maximum innovation, maximimum flexibility, and give the greatest value to the users of the net. But I don't see why allocation of new TLDs needs to be a rare event. Personally, I want a lot of new TLDs, so that folks who have silly ideas and silly business models can try em out and be given a chance to flop - but this means that there needs to be a criteria to determine flopness and to reap the failed TLDs so they don't become dead zones in the DNS hierarchy. And I think it ought to be a requirement that any idea proposed for a TLD first be prototyped somewhere down the DNS hierarchy. Anybody who wants a new TLD should have to pledge allegance to the end-to-end principle (i.e. no new sitefinders) and promise to adhere to applicable internet technical standards and practices. I also would like to start to break the semantic implications of TLD names - I'd prefer that any new ones have names that are meaningless in any language, like ts4-0k7m. Yeah this has been gone over many times - but I still have this hope that with some nudging people will stop using DNS as a directory. --karl-- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: [Ietf] New .mobi, .xxx, ... TLDs?
Iljitsch van Beijnum wrote: On 29-apr-04, at 21:18, Tony Hain wrote: This isn't true. No one is required by law to register their trademark as a domain name. IANAL, but in my discussions with lawyers focused on trademark law, in effect they are required. The perception that they are not defending their rights effectively means they abandon them. Defending their trademark doesn't necessarily mean registering every possible domain with the trademark in it, but it does usually mean going after other people who register a domain with the trademark in it. Agreed, but given the reality of legal fees the cheapest way to defend a trademark is to register it in every domain. (Although there is always the slight problem that domain names are globally unique while very few trademarks are.) While they are unique within the context of each registered country. So far, I still haven't heard a _technical_ reason against these TLD's. The technical argument here is flattening of the name space with the associated concentration higher up the tree. So what angle hierarchy is desirable? Obviously a completely flat space isn't good because the zones get too large, but a very deep space isn't either as it takes more time to recurse through. A good research topic ;) gut feel says 3-5, but YMMV /flame-suit-on/ Rather than granting new TLDs, there should be an effort to deprecate the existing non-cc TLDs and move everyone out within 3 years. The historical artifact of a failed experiment is no reason to continue down that path. So what is the rationale for organizing ourselves based on our respective countries? Trademark law is already aligned that way. If I may borrow your suit for a minute, I have another suggestion: no hard limits on TLDs, but every organization only gets to have a domain name in one TLD. So the practice of registering domain.* would have to end. And nobody can register more than one domain per year. This would have the side effect of slowing down the benefactors of the spammers. Tony ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Hi. While this discussion on the IETF list has been very interesting, it is probably worth noting that the odds of ICANN staff following the IETF list to the extent needed to pull out this thread and make use of it are not high. Instructions for making comments that they, and presumably the evaluators, will see are at http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.htm That page contains both addresses for making general comments and addresses for specific comments on each proposal, along with pointers to archives of comments made so far. The comment period on the specific applications and forms closes on 30 April (see http://www.icann.org/tlds/new-stld-rfp/new-stld-application-parta-15dec03.htm ). If those of you who have been carrying on this debate want even a chance that your positions will be carefully considered, I suggest going over to ICANN's site and posting appropriate summaries. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Mon, 26 Apr 2004, Stephen Sprunk wrote: You're confusing URI methods, protocols, and TLDs disastrously. I think it is you who is reading too much into the .tel and .mobi TLD. These are not proposals to put URI method functionality into domain names, but to qualify general business types, such as telephone companies, and mobile phone companies. This is no different from using .museum for museums and .aero to represent aerospace companies. The URI method tel: was a bad example, but otherwise completely orthogonal to the intelligibility of using .tel and .mobi TLDs. Let me restate without using the tel: method: The URL somemethod://cellularone.mobi Has a completely intelligible and meaningful interpretation. It is different from the following sip://cellularone.mobi http://cellularone.mobi telnet://cellularone.mobi etc. Similarly, sip://verizon.tel Is meaningful, and intelligible. So what is the _technical_ problem with having .tel and .mobi TLDs? A technical problem, for example, would be similar to the problem with edu.com, which if you recall, was created back in about 1994 or so. If I recall the problem, the dns searches from .com resolvers resolving .edu hosts appended their search domains to the name being resolved. So for example, ksr.com machines trying to contact mit.edu first looked up mit.edu.ksr.com., finding nothing, it tried mit.edu.com., and made a request to edu.com. Unfortunately, at the time, edu.com had a dialup connection. I see no such problems with creating .tel and .mobi TLDs. It is not the case that URI methods can't share names with TLDs. It would be fine to have a URI method of, say museum: if you could attach some sensible meaning to such a method. The tel URI method is for dialing using E.164 numbers, e.g. tel:+18005551212, which will probably be translated to a different URI via ENUM. For telephones using user/domain names, use the sip URI method, e.g. sip:[EMAIL PROTECTED]. There is no need for a .tel TLD, and adding one ignores existing, logical solutions. Likewise, there is no reason for a .mobi TLD; either mobile clients should use the standard http method to negotiate the content/format/encoding with servers as needed via HTTP's existing mechanisms, or if necessary a new method/protocol should be defined, e.g. wap://www.example.com/. I don't think you understand the proposal for the TLDs. .mobi is not for mobile _clients_. Its for mobile _Companies_ --Dean ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Thus spake Dean Anderson [EMAIL PROTECTED] These are not proposals to put URI method functionality into domain names, but to qualify general business types, such as telephone companies, and mobile phone companies. This is no different from using .museum for museums and .aero to represent aerospace companies. .aero was a waste of time, as the number of aerospace companies is so small that most users won't even realize it's a valid TLD. Ditto for telephone and mobile company TLDs. These are all far too specialized for the cost of their introduction and use to be outweighed by any benefits to the community as a whole. Now, a single gTLD which would contain SLDs for particular industries might be a worthwhile plan, but adding tens of thousands of gTLDs, one for each industry niche, is plainly not scalable. So what is the _technical_ problem with having .tel and .mobi TLDs? More importantly, in light of the human problems with that scheme in general, what is the technical benefit of having them? It won't reduce the overcrowding in .com and .net, which IMHO is the only valid reason for adding new gTLDs. Either foo://tel.verizon.com or foo://www.verizon.com/tel is far more expressive semantically than foo://www.verizon.tel. The proposal _loses_ information expressed in the hierarchy: how is a user to know foo.tel, foo.net, and foo.org are all the same company, and foo.com, foo.mobi and foo.aero are a second company with no relation to the first? A technical problem, for example, would be similar to the problem with edu.com, which if you recall, was created back in about 1994 or so. ... I see no such problems with creating .tel and .mobi TLDs. Of course there is; you risk collisions like tel.com, mobi.com, com.tel, mobi.tel, tel.mobi, etc. With a small, fixed number of TLDs the problem is manageable because most operators will naturally avoid registering such SLDs; each new TLD makes this increasingly more difficult. It is not the case that URI methods can't share names with TLDs. It would be fine to have a URI method of, say museum: if you could attach some sensible meaning to such a method. True, there's no technical conflict, but one must consider the consequences in light of the humans using them. Imagine a world with a www or com method, or a http TLD -- user error would increase exponentially. Users cannot be expected to know why com://yahoo.http has no relation to http://yahoo.com, and we should not put them in the position of needing to unless there is no alternative. I don't think you understand the proposal for the TLDs. .mobi is not for mobile _clients_. Its for mobile _Companies_ Equally bad, just for different reasons... .tel and .mobi are exceptionally bad in combination since the two would end up with nearly the same contents, given how the markets are so closely related. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Sat, Apr 24, 2004 at 01:34:06PM +0200, jfcm wrote: Dear Markus, to know where your remarks may lead, let come back to 1993. You mean like in http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1993q4.messages/579.html At 21:16 23/04/04, Markus Stumpf wrote: Hmmm ... For instance, Internet addresses ending in .mobi would allow sites built for the small screens of mobile phones. This was a cite from the article, not my opinion! If it wasn't clear from my posting: I am *against* those new TLDs. IMHO all these have their origin in that the semantic web is at best a slow starter and they try to put sematics into the web by adding semantic TLDs. Semantic web is only DNC (Domain Name Confusion) unless it uses a correct grammar (oherwise there will be nothing to sell even for the worst merchant). Grammar says the protocol is in the scheme, the intefaces in upper level names, domain name in the SLD and the interneted network in the TLD. You are talking about IMHO the syntax of URLs, I am talking about http://www.w3.org/2001/sw/ and http://www.scientificamerican.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21catID=2 where people would probably stop abusing DNS domains as registers for marketing, to reflect content in the domain name. \Maex -- SpaceNet AG| Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research Development | D-80807 Muenchen| Fax: +49 (89) 32356-299 The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Thus spake Dean Anderson [EMAIL PROTECTED] On Thu, 22 Apr 2004, jfcm wrote: .tel and .mobi are technically inconsistent propositions. They confuse what belongs to the scheme (protocol/application) with what belongs to the naming (users group). The same as was .web did in 2000. ... I have to digest the rest of this further, but I would say right away that if I connect to http://ibm.tel, I'd probably expect to reach the VOIP portal, where I could sign up for VOIP services from IBM. I'd expect that a voip connection to tel://ibm.com would get me to the headquarters switchboard, and that tel://ibm.tel gets me to the VOIP switchboard (ie VOIP customer service). You're confusing URI methods, protocols, and TLDs disastrously. The tel URI method is for dialing using E.164 numbers, e.g. tel:+18005551212, which will probably be translated to a different URI via ENUM. For telephones using user/domain names, use the sip URI method, e.g. sip:[EMAIL PROTECTED]. There is no need for a .tel TLD, and adding one ignores existing, logical solutions. Likewise, there is no reason for a .mobi TLD; either mobile clients should use the standard http method to negotiate the content/format/encoding with servers as needed via HTTP's existing mechanisms, or if necessary a new method/protocol should be defined, e.g. wap://www.example.com/. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Dear Markus, to know where your remarks may lead, let come back to 1993. At 21:16 23/04/04, Markus Stumpf wrote: Hmmm ... For instance, Internet addresses ending in .mobi would allow sites built for the small screens of mobile phones. For instance, Internet addresses (names?) ending in .web would allow sites supporting world wide web screens. Ten years before Jon Postel should have started with .ftp. From that reading I'd conclude they have no interest in registering another domain like ibm-mobile miscrosoft-mobile and so on, but rather have a new TLD where they could put ibm.mobi microsoft.mobi and so on. What about http://mobi.ibm.com IMHO it fits with the right to left concept ? (and is in line with the structural semantics below). And costs nothing. And does not add any load to the DNS. Actually, I tend to think it is why the DNS was designed ? here is no need for a .mobi (and why the hell don't they use .mobile) domain in order to deliver optimized web pages/sites. There is a very simple standard way: mobi://ibm.com - it calls for serious technical discussions. IMHO all these have their origin in that the semantic web is at best a slow starter and they try to put sematics into the web by adding semantic TLDs. Semantic web is only DNC (Domain Name Confusion) unless it uses a correct grammar (oherwise there will be nothing to sell even for the worst merchant). Grammar says the protocol is in the scheme, the intefaces in upper level names, domain name in the SLD and the interneted network in the TLD. Initially the internetted neworks were physically or geographically separated (Tymnet, telenet, ARPANET, CSNET, DOD, Transpac, Datex-P, PSS, etc.) while now they are mostly virtual (.com, .fr, .us, .int, .aero). But there a TLD is the name of a group of users or the flag of their common global interest. Not the size of the screen they use for a few months. This is precesily because because a name is to designate a lof of different applications and machines that it is called a domain name. Or should we propose .80 for all the connections to port 80 ? Let not kill something which works! There is nothing against a sub-scheme like http-mobi://ibm.com. While the mobi demand is a grammatical error as a TLD, it is perfectly legitimate as a request to the W3C. If the motivation is the service of the users, this should be the IAB/IETF advice. If the only motivation is greed and market control, IETF cannot comment.But it can tell how large common interest zones should be managed by multiple virtual zones co-registries - because IDNA will need it, to start with. So in the future we will see a lot more sponsored requests for new TLDs like insert index of yellow pages. Right. But RFC 920/1591 do not think of them as commercial private ventures. They think of them as directory members trustees. I feel this is wise thinking : IANA is not in the business of deciding what is a yellow page entry (people sharing the same interest or the same location - not the same salesman). But there are a few technical words to help them working : non profit, to the benefit of the global community, equal access for everyone matching the charter, registrants self-governance, no generic names for specific groups. To avoid conflicts, because conflicts are just a sign of the users confusion. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
At 23:49 22/04/04, Dean Anderson wrote: Is it sensible to think of tel and mobi as business functions? Absolutely yes. As I noted it, there are at least two possiblities: - .tel is accepted as the TLD of the ITU-T Sector's members. The same as for .aero. And .mobi is for all the companies, services, designers interested in mobile product, services etc. - .tel is reserved to a class of users froming an externet, ie. a class of users with special relations/access terms. This can be an economical model (rates), this can be a way of behaving (accepting or not VoSpam), etc. This however calls for a large number of new architectural concepts and naming semantic to be discussed and agreed upon. But in both cases, it is likely it would then be premature to give away such mnemonics as tel and mobi before a wide debate. ITU expressed that in their letter of 2000 to ICANN. ICANN was wise to agree. I think not much has changed. But would remain the IDNA aspect (LHS is not solved yet!), the co-registry/virtual zone need to address the support of an _existing_ and generalized non Internet industry, and the real life feed-back. Do you really think non-US Govs, ITU, users, etc. will take ICANN and IETF seriously if they give away a $ 6 yearly tax on 1.3 billion mobiles and more telephone sets, managed by State controlled corporations or monopolies, to a single private US interest? If the root was the joke of the XXth century (European Gov top expet's comment), this would be the joke of the XXIth century. The slippery slope is the risk that ICANN tries (or is put under pressures to try) that coup for political/commercial reasons. I think IETF is here to say where are the technical problems to prevent that temptation. Another point, I did not rise, is that .tel and .mobi would obviously immediately lead to propositions such as .tel1, .mob1, .phone, etc. etc. The size of the existing market and its technical sophistication would certainly push imaginations a lot and things IAB did not consider for 20 years would be implemented in chaos in months. There would be scores of New.nets. Just consider that .sms is the golden mine of today and is LOCAL. Any ISP alliance can start it today and build an externet (open virtual netwok) using ULDs (User level domains made of the alias couple of an SLD and of a local TLD) that will work very well. IAB has not published an architecture for the internetting and ICANN has contained the number of TLDs. This has not permitted the world to get a technical reference nor to establish commonly agreed best practices. Nevertheless common sense remains until this may be corrected within the global convergence/stabilization of the digital continuity. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Hi Folks, OK, I'll bite. (i) Have all of the folks commenting actually read these proposals all the way through (plus RFCs 2916 and 2806, along with the drafts RFC2806bis, and RFC2916bis that will replace them)? Some of the earlier examples in this thread make me wonder. Note that by proposals, I mean .tel-Pulver *and* .tel-Telnic (they're wildly different), as well as the .mobi proposal. AFAICT, Pulver/NetNumber seem to be proposing a competitor to .e164.arpa, whilst Telnic are suggesting a name-based (i.e. phone numbers banned) registry to hold telecomms contact data. (I leave it as an exercise for the *Advanced* student to work out exactly what mobi-JV are proposing :) (ii) After the painful/protracted discussions that led to ENUM using .e164.arpa., the idea that we throw all of that away and start again with .tel (or any other TLD) is a BAD idea, IMHO. (iii) The ITU is a UN organisation, and already has .int, so I'm not sure that there's an obvious justification for making yet another TLD available to them (quite apart from the organisational issues they have with actually registering any domains under the existing .int TLD). (iv) Regarding what mnemonics are used, and the ITU liaison to ICANN, it's illuminating to consider what was going on when the statement was sent to ICANN in 2000; the ITU had not at that point made any decision on how it was going to handle Internet use of telephone numbers, so this was a request for a block on anything that might interfere with that process. It's now 2004, and this process seems to be completing - we pretty much know what interferes and what doesn't. This, however, is a point for the IAB and the ITU. all the best, Lawrence On 23 Apr 2004, at 11:33 am, jfcm wrote: At 23:49 22/04/04, Dean Anderson wrote: Is it sensible to think of tel and mobi as business functions? Absolutely yes. As I noted it, there are at least two possiblities: - .tel is accepted as the TLD of the ITU-T Sector's members. The same as for .aero. And .mobi is for all the companies, services, designers interested in mobile product, services etc. - .tel is reserved to a class of users froming an externet, ie. a class of users with special relations/access terms. This can be an economical model (rates), this can be a way of behaving (accepting or not VoSpam), etc. This however calls for a large number of new architectural concepts and naming semantic to be discussed and agreed upon. But in both cases, it is likely it would then be premature to give away such mnemonics as tel and mobi before a wide debate. ITU expressed that in their letter of 2000 to ICANN. ICANN was wise to agree. I think not much has changed. snip ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
At 19:08 21/04/04, Dean Anderson wrote: I suspect I am going to regret asking, but how is this a slippery slope, and why should anyone be against it? Perhaps more to the point, why should the IETF have any interest whatsoever? May be should I respond this as I do agree with slippery slope and I am known to support a far wider number of TLDs. Also because I think the issue is crucial. First, I am afraid John is wrong when he refers to RFC 1591 as having started it. Actually Tim is right : it has not started yet, or only partly started in 2000. Please refer yourself to RFC 920 and previous RFCs on DNS. DNS is the naming system of the legacy ARPANET Internet. It was aggregated to the international naming scheme in 1984 after meeting the operators of the external networks, since 1983 RFC 880/2. DoD/ARPA meeting with Tymnet in 12.83, Tymnet annoucement of IP support early 84. Some in here participated and might comment. What is important is that the today situation is similar and that the 1984 consensus described in RFC 920 has proven to be stable and good enough for 33 years (cf.infra). As Vint says, why to change something which works? The target was, as it is today, to get accepted end to end interoperability with more external systems. This meant openness, no conflict, naming format consistency and credibility. Actually RFC 920 describes the way it developed since 1971 (first commercial user) and 1977 (beginning of the global interconnects) and the way Internet could nicely insert itself into it. Internet did it so seamlessly that it took over. 1. the different connected real (COM, NET) or virtual (EDU) networks had their root names (names of their root into the APANET Internet) accepted (they are named TLD in the DNS jargon). As the ARPANET Internet had its ARPA root name. 2. the global backbone was, by then, the international public packet switch system by monopolies and common carriers. It used Tymnet or X.25/75 links and identified networks (real and virtual) in either using ISO 3166 3 letter codes or X.121 DCCs. Some virtual communities networks (externets) piped (refilled) their traffic through it. The largest number were the Telex refillers. They were identified for their support and some naming through Telex ISO 3166 2 letter codes. RFC 920 only uses that common practice in foreseeing ccTLDs (RFC 1591 introduces nothing new, and its rightfully that ICANN claims its legitimacy over the Legacy from RFC 920 and 921 - cf. ICP-3). In 1986 Austrian people forged the IP address cluster concept to support their Internet island (through Tymnet and X.25 link by Radio Austria). Then IETF was created and changed nothing. Why to change something which works? 3. RFC 920 details the process of creating new TLDs. The need is to avoid conflict with other existing names (like today Macedonia for country names) and the name to be accepted in the root files of all the inter-netted networks. By then, the de facto world referent being the Tymnet registry, the retained RFC 920 rule is its best practice, based on its international experience since 1977. It calls for an expected significant number of domain owners (500 is quoted) to credibly organize it together (multiorganization TLDs). Experience had shown it warranted the projects to be serious, open enough to avoid conflicts, credible enough to be accepted by other operators and by the market and to rise enough commercial interest to foot the various costs involved. RFC 1591 confirms this in describing the TLD Manager as the trustee of his community and in saying that IANA is not in the business of saying what is a country (the same as ICANN should not be in the business of saying what is a TLD). If IANA/ICANN are not in the business of saying what is a TLD, IETF is however in the business of saying what is technically _not_ a TLD. .tel and .mobi are technically inconsistent propositions. They confuse what belongs to the scheme (protocol/application) with what belongs to the naming (users group). The same as was .web did in 2000. To better understand, let take the mnemonic IBM and its ASCII domain name ibm.com. - when I enter http://ibm.com I expect to reach the IBM web site in using the HTTP protocol. - when I enter tel://ibm.com I expect to reach the IBM switchboard (once the current VoIP delaying confusion is cleared). - what will I expect to reach when entering http://ibm.tel, and what is tel://ibm.tel adding to me ? Actually they create at least four major technical problems: 1. a conflict with multilingualization while MINC is working hard to implement IDNA and to test a response to the ML.ML urgency. .tel or .mobi are application oriented and are not multilingual. How do I know the _language_ that an English or a French sounding name will use. How will I give my xn.tel Arabic name to a Chinese correspondent? 2. real demand IMHO goes far beyond ML. I think it goes to total
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Thu, 22 Apr 2004, jfcm wrote: .tel and .mobi are technically inconsistent propositions. They confuse what belongs to the scheme (protocol/application) with what belongs to the naming (users group). The same as was .web did in 2000. To better understand, let take the mnemonic IBM and its ASCII domain name ibm.com. - when I enter http://ibm.com I expect to reach the IBM web site in using the HTTP protocol. - when I enter tel://ibm.com I expect to reach the IBM switchboard (once the current VoIP delaying confusion is cleared). - what will I expect to reach when entering http://ibm.tel, and what is tel://ibm.tel adding to me ? I have to digest the rest of this further, but I would say right away that if I connect to http://ibm.tel, I'd probably expect to reach the VOIP portal, where I could sign up for VOIP services from IBM. I'd expect that a voip connection to tel://ibm.com would get me to the headquarters switchboard, and that tel://ibm.tel gets me to the VOIP switchboard (ie VOIP customer service). Similarly, I'd expect that tel://ibm.mobi gets me to the IBM Cellular switchboard. I recall that gte internetworking used gte.com for internal corporate addresses and gte.net for customer addresses. Some companies use subdomains for such purposes. --Dean ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Thu, 22 Apr 2004, Joe Touch wrote: The tel: part is sufficient to get you to VOIP - in fact, that's what tel: ought to mean -- no more, no less. If you want IBM to differentiate the switchboard from the headquarters, try: tel://ibm.com/hq- headquarters-specific tel://ibm.com/ - default switchboard Similarly, I'd expect that tel://ibm.mobi gets me to the IBM Cellular switchboard. tel://ibm.com/cell I.e., that's a decision IBM gets to make; others can decide, e.g., that cell and regular calls all go through the same VOIP gateway. Well, why not just run everything over http and have an application-type header to destinguish the different formats? Possible, but not quite ideal, since then you are stuck with an HTTP server in the middle. I recall that gte internetworking used gte.com for internal corporate addresses and gte.net for customer addresses. Some companies use subdomains for such purposes. Sure, but that is different than the above. In the tel: cases, all the addresses are for internal corporate, not for a service IBM runs for its customers. Umm, I don't see how. Its just using naming, and specifically different TLD's to make a distinction between corporate and customer functions. No matter what you do, you are probably going to use naming anyway, either as a url path component, or as a subdomain, or as a new TLD. I don't see any significant operational difference(*), nor any particularly significant technical differences to them. Except, I'd probably prefer not to send everything through http, so that tends to go against the use of url pathnames and application-types as discriminators. What difference does it make to the IETF whether there are more TLD's or less? (*) Having more TLD's ought to improve the reliability of the internet in general by distributing load off the overused com and net domain servers. Whether you have 259 TLDs or 2500 isn't going to make a great deal of difference to the root servers, as these aren't particularly large zones. 2500 TLDs would no doubt make some measurable impact on the roots, but it would make a hugely big difference in directing traffic off the com and net servers which have millions of entries. And we aren't talking about 2500 TLDs, though. We are talking about just adding a handful. This isn't a significant difference, and may not even be measurable. On the other hand, I would also note that the com and net domains are commercial, and charge fees for their operation. I don't see that the IETF or ICANN necessarilly cares either way how much that operation costs, or that it should be concerned very much with reducing those costs with more TLD's. But I'd also say that extreme disregard for costs would be a bad thing. So I'd say that's a wash. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
On Thu, 22 Apr 2004, Joe Touch wrote: What difference does it make to the IETF whether there are more TLD's or less? Nothing in general; what matters, as jfc already put very well, is that these particular TLDs are acting in place of a function that is already provided by the protocol field. Ok. So the difference is that mobi and tel indicate an application function, whereas net, com, cc, biz, info, museum, org, etc tend to indicate business/organiation function? (leaving out country codes--which indicate locale) Is it sensible to think of tel and mobi as business functions? --Dean ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
[Ietf] New .mobi, .xxx, ... TLDs?
Hi, Is the IETF or ISOC going to take any stance against this slippery slope? http://www.cnn.com/2004/TECH/internet/03/20/new.domains.ap/ Comment period closes April 30th. Tim ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
--On Wednesday, 21 April, 2004 15:46 +0100 Tim Chown [EMAIL PROTECTED] wrote: Hi, Is the IETF or ISOC going to take any stance against this slippery slope? http://www.cnn.com/2004/TECH/internet/03/20/new.domains.ap/ Comment period closes April 30th. Tim, Addressing the IETF part of your question only, let me turn the question around. On what basis would you see the IETF objecting? Certainly the general notion of what ICANN now calls a sponsored (restricted-use) non-country TLD is nothing new: in theory (and in practice for a significant number of years), NET, EDU, and others were domains in which one had to meet specific requirements to register. So, if there is a slippery slope there, we were down it before RFC 1591 was written. Clearly, there is a case to be made that at least some of these proposals are problematic in one way or another and that some of the issues are technical or operational. But those issues are presumably different for different proposals. So what would you have the IETF say, and how would you propose organizing a process to approve such a statement, ideally between now and April 30? As a specific example, RFC 3675 addresses some of the issues with at least one of these proposals. But it largely addresses policy issues, rather than technical ones, and is an individual-submission informational RFC. Would you propose that the IETF endorse it and recommend to ICANN that they pay attention to it and, if so, on what basis? Note that these are just questions to think about -- I've got opinions on some of these issues, but hope that you cannot deduce them from this particular note. regards, john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
I suspect I am going to regret asking, but how is this a slippery slope, and why should anyone be against it? Perhaps more to the point, why should the IETF have any interest whatsoever? --Dean On Wed, 21 Apr 2004, Tim Chown wrote: Hi, Is the IETF or ISOC going to take any stance against this slippery slope? http://www.cnn.com/2004/TECH/internet/03/20/new.domains.ap/ Comment period closes April 30th. Tim ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
