Re: Some data Re: Again: Number of Firewall/NAT Users
In message [EMAIL PROTECTED], Kyle Lussier typ ed: "is anyone aware of any estimations of fraction of Internet users who are behind firewalls and NATs?" How about for business users? If the assumption can be made that most Q3 players are home based (which would probably have a lower incidence of NATs) ~20% sounds high. Of course that could be because of sevice providers. according to some measurements, most game players are at WORK. + in some parts of the world, most HOME users aere behind NATs But does anyone have a better idea for business users? cheers jon
Multicast
Hello, First the CBT protocol was created to use shared tree solutions because DVMRP and the other dense mode protocols werent scalable. there were many problems with CBT (which is bidirectional) so PIM-SM was cretaed which provide some switching (between shared tree and source tree). and after that there is some discussions about the bidirectional PIM, which is like CBT. Are we in circle here or what ??
Re: Multicast
In message [EMAIL PROTECTED], Ali Boudani typed: First the CBT protocol was created to use shared tree solutions because DVMRP and the other dense mode protocols werent scalable. there were many problems with CBT (which is bidirectional) so PIM-SM was cretaed which provide some switching (between shared tree and source tree). and after that there is some discussions about the bidirectional PIM, which is like CBT. Are we in circle here or what ?? not really. the mainstream current multicast action is concentrating on single source (and on single source reliable multicast transport) since we didn't feel we understood all the complications of ANY of the multiple source schemes for IP or reliable(e.g. interdomain routing, and multiple source semantics for reliable) - there were'nt really "problems" with CBT apart from we never managed to get a router vendor to committ to an implmenetation which we could deploy and learn from - tony ballardie got a lot of the details out, but the two implementaions i know of never saw light of day.bidir pim is cool, bgmp is cool, but action in implementation/details/spec is waiting on getting the PIM SSM stuff completely shaken down its all part of a good learning experience and (as any good s/w engineer might say) its the norm:-) cheers jon
Re: Multicast
In message [EMAIL PROTECTED], Ali Boudani typed: Isnt SSM just a particular case of PIM?? the right place for this discussion is SSM [EMAIL PROTECTED], SSM is a subset of PIM SM, roughly, and relies (sort of) on IGMPv3 (at least on a subset of equiv. functionality). It is the specifications for just specific sources but they arent adressing the multicast in general. am I right ? not quite - i dont think the whole IETF list is the right place for this one - see http://www.ietf.org/html.charters/ssm-charter.html i think since the ssm work is close to done, we'll see work resume on bidir (s/cbt/pim-bidir:-) soon , and similalrly in the RMT work see http://www.ietf.org/html.charters/rmt-charter.html a lot of building blocks are close to done (prob. about a year) then we'll see some work on multiple source (the latent demand for multiple source applications is imho underestimated, but until we can fix the more immediate problems with supporting 1-many, we can't really expect people to deploy many-to-many extensively- other problems being addressed are concerned with having good solutions for multicast security (see http://www.ietf.org/html.charters/msec-charter.html and for many-to-many, for congestion control (to meet transport area requirements) i think (but of course i am usually wrong) that we may see progress on this in 2002... Jon Crowcroft wrote: In message [EMAIL PROTECTED], Ali Boudani typed: First the CBT protocol was created to use shared tree solutions because DVMRP and the other dense mode protocols werent scalable. there were many problems with CBT (which is bidirectional) so PIM-SM was cretaed which provide some switching (between shared tree and source tree). and after that there is some discussions about the bidirectional PIM, which is like CBT. Are we in circle here or what ?? not really. the mainstream current multicast action is concentrating on single source (and on single source reliable multicast transport) since we didn't feel we understood all the complications of ANY of the multiple source schemes for IP or reliable(e.g. interdomain routing, and multiple source semantics for reliable) - there were'nt really "problems" with CBT apart from we never managed to get a router vendor to committ to an implmenetation which we could deploy and learn from - tony ballardie got a lot of the details out, but the two implementaions i know of never saw light of day.bidir pim is cool, bgmp is cool, but action in implementation/details/spec is waiting on getting the PIM SSM stuff completely shaken down its all part of a good learning experience and (as any good s/w engineer might say) its the norm:-) cheers jon cheers jon
Re: Multicast
Ali; Hello, First the CBT protocol was created to use shared tree solutions because DVMRP and the other dense mode protocols werent scalable. there were many problems with CBT (which is bidirectional) so PIM-SM was cretaed which provide some switching (between shared tree and source tree). and after that there is some discussions about the bidirectional PIM, which is like CBT. Are we in circle here or what ?? If there were some progress somewhere, you might be able say "circle". But, in IETF, no proposal makes any sense that there is absolutely no movement. Here, you are on a point behind a start line. SSM is no different. The real difficulty of multicast is in the various relationships to resource reservation. I've heard that ISPs, which were expecting to receive special charge for multicast service, are now bitterly recognizing one aspect of the relationship that, even if multicast is free, customers do not bother to use multicast if they pay flat rate to receive any amount of unicast traffic Those serving the customers simply increase the number of capacity of servers, of course. Masataka Ohta
Multicast
Hi, regarding the statement made by Jon that SSM is a subset of PIM-SM, Isnt it true that SSM just refers to providing a host with the multicast session from one particular source even if the underlying protocol scheme is DVMRP or even OSPF. As far as I know, SSM has more to do with the IGMPv3 then to PIM-SM. Regards Pathik Gupta -Original Message- From: Jon Crowcroft [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 07, 2001 7:11 PM To: Ali Boudani Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Multicast In message [EMAIL PROTECTED], Ali Boudani typed: Isnt SSM just a particular case of PIM?? the right place for this discussion is SSM [EMAIL PROTECTED], SSM is a subset of PIM SM, roughly, and relies (sort of) on IGMPv3 (at least on a subset of equiv. functionality). It is the specifications for just specific sources but they arent adressing the multicast in general. am I right ? not quite - i dont think the whole IETF list is the right place for this one - see http://www.ietf.org/html.charters/ssm-charter.html i think since the ssm work is close to done, we'll see work resume on bidir (s/cbt/pim-bidir:-) soon , and similalrly in the RMT work see http://www.ietf.org/html.charters/rmt-charter.html a lot of building blocks are close to done (prob. about a year) then we'll see some work on multiple source (the latent demand for multiple source applications is imho underestimated, but until we can fix the more immediate problems with supporting 1-many, we can't really expect people to deploy many-to-many extensively- other problems being addressed are concerned with having good solutions for multicast security (see http://www.ietf.org/html.charters/msec-charter.html and for many-to-many, for congestion control (to meet transport area requirements) i think (but of course i am usually wrong) that we may see progress on this in 2002... Jon Crowcroft wrote: In message [EMAIL PROTECTED], Ali Boudani typed: First the CBT protocol was created to use shared tree solutions because DVMRP and the other dense mode protocols werent scalable. there were many problems with CBT (which is bidirectional) so PIM-SM was cretaed which provide some switching (between shared tree and source tree). and after that there is some discussions about the bidirectional PIM, which is like CBT. Are we in circle here or what ?? not really. the mainstream current multicast action is concentrating on single source (and on single source reliable multicast transport) since we didn't feel we understood all the complications of ANY of the multiple source schemes for IP or reliable(e.g. interdomain routing, and multiple source semantics for reliable) - there were'nt really "problems" with CBT apart from we never managed to get a router vendor to committ to an implmenetation which we could deploy and learn from - tony ballardie got a lot of the details out, but the two implementaions i know of never saw light of day.bidir pim is cool, bgmp is cool, but action in implementation/details/spec is waiting on getting the PIM SSM stuff completely shaken down its all part of a good learning experience and (as any good s/w engineer might say) its the norm:-) cheers jon cheers jon
Re: Multicast
Hello, are you suggesting that there is no multicast problem :-) and that is the ordinary unicast problems related to ressource reservation and by expanding the capacity of servers and also of the link bandwidth that problem will be solved. :-) thanx Masataka Ohta wrote: Ali; Hello, First the CBT protocol was created to use shared tree solutions because DVMRP and the other dense mode protocols werent scalable. there were many problems with CBT (which is bidirectional) so PIM-SM was cretaed which provide some switching (between shared tree and source tree). and after that there is some discussions about the bidirectional PIM, which is like CBT. Are we in circle here or what ?? If there were some progress somewhere, you might be able say "circle". But, in IETF, no proposal makes any sense that there is absolutely no movement. Here, you are on a point behind a start line. SSM is no different. The real difficulty of multicast is in the various relationships to resource reservation. I've heard that ISPs, which were expecting to receive special charge for multicast service, are now bitterly recognizing one aspect of the relationship that, even if multicast is free, customers do not bother to use multicast if they pay flat rate to receive any amount of unicast traffic Those serving the customers simply increase the number of capacity of servers, of course. Masataka Ohta
Re: Multicast
Ali; are you suggesting that there is no multicast problem :-) There is none remaining. and that is the ordinary unicast problems related to ressource reservation and by expanding the capacity of servers and also of the link bandwidth that problem will be solved. :-) I'm saying it was simple and easy to solve the resource reservation and multicast problems at once (www.real-internet.org). You can see that RSVP has a fatal flaw trying to accomodate all the possible and impossible multicast protocols. Another interesting aspect of the relationship is that each multicast group consumes a precious resource of routing table entry that multicast is a resource reserving communication. Masataka Ohta
Re: Multicast
The real difficulty of multicast is in the various relationships to resource reservation. This is so completely wrong... Multicast is cheaper than unicast from every resource perspective. It uses fewer network resources for both content providers and consumers. It even uses fewer resources for network providers. "The real difficulty of multicast" is that it's much more difficult for ISP's (and presumably router venders) to support than unicast. brad
Re: Multicast
Masataka Ohta wrote: are you suggesting that there is no multicast problem :-) There is none remaining. Well, what about scalability, and the interoperability with the underlying unicast protocols. and what about the interdomain multicast??? I'm saying it was simple and easy to solve the resource reservation and multicast problems at once (www.real-internet.org). Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English) or there is another one?? I didnt found it in the internet-drafts at the IETF !!! thanx
Re: Multicast
Ohta san, ISP talking with you intend to charge whether sender, reciever or both ? I guess some ISP would not like to start multicast service, even if subscriber request it. They might sometimes say as an excuse what you heard. I think there are a lot of way to make a special charge for special service without resource reservation protocol as you think, even if you say "It is not scalable way" :) Masataka Ohta wrote: I've heard that ISPs, which were expecting to receive special charge for multicast service, are now bitterly recognizing one aspect of the relationship that, even if multicast is free, customers do not bother to use multicast if they pay flat rate to receive any amount of unicast traffic
Re: Multicast
Kobayashi san; ISP talking with you intend to charge whether sender, reciever or both ? I guess some ISP would not like to start multicast service, even if subscriber request it. They might sometimes say as an excuse what you heard. I think there are a lot of way to make a special charge for special service without resource reservation protocol as you think, even if you say "It is not scalable way" :) You completely miss the point. Because best effort service is flat rated, receivers are not motivated to use multicast. Senders learned to have more servers. See my column article on the most recent IPSJ magazine for details. That's all. Masataka Ohta
Re: Multicast
Brad Hunting writes: | It even uses fewer resources for network providers. | | "The real difficulty of multicast" is that it's much more difficult | for ISP's (and presumably router venders) to support than unicast. These two statements are, unfortunately, mutually exclusive. IP multicast does not scale well for S,G state; it may scale OK for *,G for reasonable numbers of groups; it is not known whether it will scale at all for little things like customer support. Several backbones (including Ebone) offer native multicast "for free"; all a customer has to do is configure things up: for source-active/rendezvous: use our (anycast) RP, talk MSDP to us for RPF: use mBGP for joins/prunes: use PIM in sparse mode It's not so difficult to set up, but not many people actually do it. A sister network which has a pretty similar overall architecture to ours offers multicast "for free" with a transmissions cap of a few hundred kbps or so from a customer to the rest of the world through that network. I don't think that this threshold has ever been in the way of anyone so far... Why? Poor client support springs to mind. I've always wanted to have someone throw together a web page that downloads a Java applet equivalent to vic/vat/rat/etc., joins the right group, and puts content into the face of the clicker, perhaps for a fee. However, in the absence of compelling content (sadly we don't have Vint to strip for us :) ), I haven't suggested that this be a priority. Also, not all routers at/near the edge can even do native multicast... Sean. P.S.: A long time ago there was a very interesting discussion (probably on NANOG) involving Vadim Antonov and many others; the argument advanced by Vadim's side (include me here) is, roughly, that if you consider multicast to be a degenerate form of caching, where the cache is purged immediately after servicing the implicit cache requests made by the listeners who have joined below the current router, then native multicast, particularly reliable native multicast, is being approached in fundamentally the wrong fashion. In other words, rolling (maybe short term) content caching into (some) routers is likely to be a more useful generalized service than deploying actual native multicast, all while being able to reuse some join/prune, SA and RPF state handling to optimize the "network-based Content Distribution Network" (to use a set of buzzwords).
Re: Multicast
| Well, what about scalability, and the interoperability with the underlying unicast | protocols. and what about the interdomain multicast??? IDR for multicast is pretty straightforward: 1. discovering sources: SA handling done by MSDP works OK, there are maybe better ways of doing it simple policies are sufficient: i don't want to know about sources going active from your network for some reason, so i'll filter them out. i don't want you to know about my source going active (perhaps because the source isn't paying me) so i won't announce it to you 2. handling joins/prunes: PIM in sparse mode works OK, there are maybe better ways of doing it possibly complicated policies, particularly on joins: i don't want to hear your join to groups whose sources are across the ocean, unless some customer of mine has already joined and is causing the traffic to flow anyway i will happily dump traffic "for free" onto an IX if a paying customer on a router "right beside" the IX (or at the IX) joins a group i will pick up traffic dumped "for free" onto an IX and forestall a join towards the distant source while the traffic is there i do want your customer's joins, but not your peers' joins; those i will drop on the floor 3. handling RPF: mBGP okay, this is the "worst part", since the policy opportunities here are endless. however, what should be done here is mainly forwarding loop avoidance; policy one would want to express here (do not propagate out interface X) should be expressed in some other way -- probably join control, however that ignores some brutal realities about rebuilding trees when lines/routers fail. | Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English) | or there is another one?? | I didnt found it in the internet-drafts at the IETF !!! Good, RSVP for multicast is an insane idea. There is a finite but nearly zero chance that an ISP will ever squeeze more money out of someone by promising them via RSVP that their multicast packets will make it through from source to destination, whether the someone is a source or a listener. However, if you demonstrate compliance with an SLA that works like many unicast ones (x% packet loss, y ms delay, from network edge to network edge), you may be able to charge more for "best efforts" multicast, and pick up customers who are frustrated with RSVP stuff. "Simple" RSVP: say yes always, or say no always. Choose one. Sean.
Re: Multicast
Sean; | Because best effort service is flat rated, receivers are not motivated | to use multicast. Senders learned to have more servers. Yes, but some senders would like to send a bit less :-) By definition, majority is taken by the receivers. ;-) Masataka Ohta
Re: Multicast
Greg; The multicast test button we wrote : http://www.multicasttech.com/mt/ http://www.on-the-i.com/mt/test_ns.html is a Java applet, and it joins a group. The secret was in getting the right certificates and authorizations. This seems to still be the problem with the Mac. Marshall Greg Shepherd wrote: Why? Poor client support springs to mind. I've always wanted to have someone throw together a web page that downloads a Java applet equivalent to vic/vat/rat/etc., joins the right group, and puts content into the face of the clicker, perhaps for a fee. However, in the absence of compelling content (sadly we don't have Vint to strip for us :) ), I haven't suggested that this be a priority. I often thought of the same, but the current Java Applet security model prevents applets from joining mcast groups; or at least did last I looked. Greg Also, not all routers at/near the edge can even do native multicast... Sean. P.S.: A long time ago there was a very interesting discussion (probably on NANOG) involving Vadim Antonov and many others; the argument advanced by Vadim's side (include me here) is, roughly, that if you consider multicast to be a degenerate form of caching, where the cache is purged immediately after servicing the implicit cache requests made by the listeners who have joined below the current router, then native multicast, particularly reliable native multicast, is being approached in fundamentally the wrong fashion. In other words, rolling (maybe short term) content caching into (some) routers is likely to be a more useful generalized service than deploying actual native multicast, all while being able to reuse some join/prune, SA and RPF state handling to optimize the "network-based Content Distribution Network" (to use a set of buzzwords). -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.on-the-i.com
Re: Multicast
Okay, so signed applets work? Good. Thanks, Greg On Wed, 7 Mar 2001, Marshall Eubanks wrote: Greg; The multicast test button we wrote : http://www.multicasttech.com/mt/ http://www.on-the-i.com/mt/test_ns.html is a Java applet, and it joins a group. The secret was in getting the right certificates and authorizations. This seems to still be the problem with the Mac. Marshall Greg Shepherd wrote: Why? Poor client support springs to mind. I've always wanted to have someone throw together a web page that downloads a Java applet equivalent to vic/vat/rat/etc., joins the right group, and puts content into the face of the clicker, perhaps for a fee. However, in the absence of compelling content (sadly we don't have Vint to strip for us :) ), I haven't suggested that this be a priority. I often thought of the same, but the current Java Applet security model prevents applets from joining mcast groups; or at least did last I looked. Greg Also, not all routers at/near the edge can even do native multicast... Sean. P.S.: A long time ago there was a very interesting discussion (probably on NANOG) involving Vadim Antonov and many others; the argument advanced by Vadim's side (include me here) is, roughly, that if you consider multicast to be a degenerate form of caching, where the cache is purged immediately after servicing the implicit cache requests made by the listeners who have joined below the current router, then native multicast, particularly reliable native multicast, is being approached in fundamentally the wrong fashion. In other words, rolling (maybe short term) content caching into (some) routers is likely to be a more useful generalized service than deploying actual native multicast, all while being able to reuse some join/prune, SA and RPF state handling to optimize the "network-based Content Distribution Network" (to use a set of buzzwords). -- Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.on-the-i.com
Re: An I-D experiment (Re: HTML better for small PDAs)
A premise behind the formatting rules for IETF documents is that they are easy to create and easy to read. As popular as XML is in the minds of the technical community, there are few tools for creating it and little widespread use of it. So far. dave - i think this is one of those ymmv things. i know a lot of people who do a lot of xml input using wysiwyg editors. rfc 2629 listed a couple of tools from a couple of years ago, there are a lot more out there now. in other words, i politely question the basis for your assertion above. for myself, i use emacs simply because i can use it to edit all kinds of files on all kinds of systems. this is a trade-off from having xml-specific support, but that's okay. finally, for those folks who are using the rfc2629-based tool called xml2rfc: there is a new release available that generates nroff, in addition to txt (rfc 2223) and html. the reason why it generates nroff is that you can give that to the rfc-editor along with your txt file and it gives them a leg up on their editing process - http://xml.resource.org/ /mtr
Is it an error?
In Rfc2868 (RADIUS Attributes for Tunnel Protocol Support), Radius Attribute 91 is given to Tunnel-Server-Auth-ID. However, In Rfc2888 (Secure Remote Access with L2TP),the same Radius Attribute 91 is given to IPSEC_MANDATE. Is it an error?
How to Secure L2tp with IPSEC at LAC?
Is there a new Radius Attribute to tell LAC how to Secure L2tp? How to offer various service to various user belong to one Company? (One may need encryption,one need data integrity,one may need none)
ID Archive again,
Last year I remember we had a talk over the ID archive. (The original motivation of it was IDs as references of officialy released technical documents.) Somebody said, as I remember, "Some secretariats are making an ID archive in which none of it never expires." : Any news ? Jiwoong
Curiosity
Questions. Is it a good tradition to form a 'design team' in a WG and to let that group design something excluding the rest of the WG, and to accept the design result as a WG official opinion ? Second one. Is it a good tradition not to ask consensus from the audience at the IETF meeting site, if the design team is made of 'core and active' members in it ? Final one. Is it a good tradition to consume most of the meeting time in debating technical matters of an ID, between the AUTHORS of that ID ? PS. What rights does a WG chair have ? I hope this coming IETF meeting opens its door to all. many replies plz. Thank you so much. Jiwoong
Re: Curiosity
Questions. Is it a good tradition to form a 'design team' in a WG and to let that group design something excluding the rest of the WG, and to accept the design result as a WG official opinion ? No. Anyone can form a design team, but no design team has the right to speak for the group in its decision making. The most a design team can do is submit proposals and try to gain consensus on those proposals. the group is free to adopt them, ignore them, or modify them as needed. and "official" design teams have no more right to a presumption of their proposals being adopted than "unofficial" ones. Second one. Is it a good tradition not to ask consensus from the audience at the IETF meeting site, if the design team is made of 'core and active' members in it ? No. no design team can dictate consensus. Final one. Is it a good tradition to consume most of the meeting time in debating technical matters of an ID, between the AUTHORS of that ID ? Authors are recognized because they've made substantial contributions; they are not required to be in full agreement. IMHO, arguments between the authors are as valid a use of meeting time as any other arguments - just as long as the authors don't exclude other parties from providing input. A good chair will not let an argument run too long if it's not making useful headway - the participants will be told to take it to the hallway, bar and/or mailing list. Keith
Re: Multicast
Sean; | Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English) | or there is another one?? | I didnt found it in the internet-drafts at the IETF !!! Good, RSVP for multicast is an insane idea. There is a finite but nearly zero chance that an ISP will ever squeeze more money out of someone by promising them via RSVP that their multicast packets will make it through from source to destination, whether the someone is a source or a listener. ISPs can squeeze more money with resource reserved unicast. ISPs can squeeze less money with resource reserved multicast, which is why, with resource reserved communication, source or listener are motivated to use multicast. Then, with free competition between ISPs, some ISP is motivated to offer multicast. However, if you demonstrate compliance with an SLA that works like many unicast ones (x% packet loss, y ms delay, from network edge to network edge), you may be able to charge more for "best efforts" multicast, and pick up customers who are frustrated with RSVP stuff. To make it operationally scale without spending infinite amount of money on network operators (:-), we need a fully automated signaling protocol. "Simple" RSVP: say yes always, or say no always. Choose one. RSVP is complex partly because of filter spec, which is unnecessary with shared-tree unidirectional PIM, and half hearted support of half-reliable link local multicast, which is unnecessary as, following the CATENET model, internet should not include large link layer, which ATM network dreamed to be. Masataka Ohta
FW: Last Call: RFC1403, BGP OSPF Interaction, to Historic
-- From: Sanjay Krishna Kuhikar Sent: Wednesday, March 07, 2001 11:46 PM To: [EMAIL PROTECTED] Cc: # NETBRAHMA - RPG Subject: RE: Last Call: RFC1403, BGP OSPF Interaction, to Historic Hi, I was looking for the reason why RFC 1403 is proposed for Historic Status. Can you please help me to understand it. As per my understanding the ospf/bgp interaction and bgp/idrp-ospf interaction is very much required. I will appreciate even if I get pointers from where I can get this informations. Regards Sanjay Kuhikar -- From: The IESG[SMTP:[EMAIL PROTECTED]] Reply To: [EMAIL PROTECTED] Sent: Tuesday, March 06, 2001 5:19 PM Cc: [EMAIL PROTECTED] Subject: Last Call: RFC1403, BGP OSPF Interaction, to Historic The IESG has received a request to reclassify RFC1403 'BGP OSPF Interaction' as an Historic document. The original document was a product of the Inter-Domain Routing Working Group of the IETF and is currently a Proposed Standard. The IESG will also consider publication of Request to Move RFC1403 to Historic Status draft-meyer-rfc1403-historic-00.txt as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by April 6, 2001.
An historic URL
I found one interesting prehistoric URL expression at the last page of RFC 826. It says, ...(thanks to MOON@SCRC@MIT-MC). That RFC was written in 19 years ago and I don't know what was going on in ARPANET at that time. That old expression shows some interesing points. A. It has muliple "@" symbols. B. All letters are capital. C. It doesn't include any dots. Interesting. Could some archaeologists please explain this hieroglyph ? BTW, where and when the current version of URL was defined ? Thanks for your great info. Regards, Jiwoong
