Re: where the indirection layer belongs
Dave, Dave Crocker wrote: DC In general I suggest we find some specific scenarios that require a new DC construct for end-point identifiers. ... Concrete scenarios are very good indeed. PN On the other hand, security looks to me as a good reason for PN having stable end-point identifiers. DC and rendezvous. DC any reference to an object that requires use outside of an existing DC context. Well, I consider an *identifier* as something that is more or less intrisically bound to an identity and a *name* as something that merely indicates an entity, i.e., involves indirection. In other words, an identifier implies sameness and stability of the identified entity, while a name does not have those connotations to the same extent. From this point of view, IP addresses are identifiers. However, they are not end-point identifiers but identifiers for topological locations within the routed network. Now, you may be able to do rendezvous with just names, e.g., with domain names. And for referencing external objects, it is often much better to use names than identifiers. Furthermore, I find it hard to imagine situations where you want to reference objects that are really outside of any context; IMHO there is always some context, and names are always bound to such a context. PN Even facing the danger of opening yet another rat hole, in my PN opinion we should not have a very strict definition for end-point. PN ... PN From my point of view, an end-point may be a process, a group of PN processes, a host, or even a server cluster offering services as DC Just for fun, let's start by using the term domain name and try to DC understand why it will not suffice. DC DC domain names have been successfully used for all of the examples you DC give. In my opinion, domain names are probably good for coarse grain rendezvous and expecially object reference (e.g. URLs). They have their problems in disconnected networks, but LLMNR / mDNS seems to help there. On the other hand, domain names are not very good for security. You need some external infrastructure, and unfortunately our strawman economic analysis shows that secure DNS may be economicly infeasibile. The cost of security is a crusial issue here. One of the success factors of SSH has been the low deployment cost. --Pekka Nikander
RE: Solving the right problems ...
We've tested similar mechanism with SRV and performance seems does not suffer. /Yuri -Original Message- From: Henry Sinnreich [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 7:46 PM To: 'vinton g. cerf'; [EMAIL PROTECTED] Cc: Richard Shockey; Christian Stredicke Subject: RE: Solving the right problems ... Could one use the NAPTR concept to create a new identifier space with specific dynamics? It would take two lookups: one to DNS to get the NAPTR and one to resolve the NAPTR identifier into an IP address. We will be soon able to test the speed of such a mechanism with the NAPTR client built into SIP phones that are just emerging. I have copied here its developer, Christian Stredicke and the ENUM co-chair Richard Shockey to answer questions on this. Thanks, Henry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of vinton g. cerf Sent: Wednesday, August 27, 2003 10:09 PM To: [EMAIL PROTECTED] Subject: RE: Solving the right problems ... If you look at the instant messaging systems, they map a private identifier space (IM name or handle) into IP addresses and apparently run background heartbeat to re-assign the mapping if the identifier in the heartbeat arrives in a packet with a different IP address than before - not sure whether or how hijack is avoided. Could one use the NAPTR concept to create a new identifier space with specific dynamics? It would take two lookups: one to DNS to get the NAPTR and one to resolve the NAPTR identifier into an IP address. The latter resolution need not necessarily be done via DNS. vint Vint Cerf SVP Technology Strategy MCI 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 703 886 1690 (v806 1690) 703 886 0047 fax [EMAIL PROTECTED] www.mci.com/cerfsup
Re: A modest proposal - allow the ID repository to hold xml
On Wed, 3 Sep 2003, Jari Arkko wrote: I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. One of the primary reasons for proposing XML as the canonical RFC format is that these other formats (ASCII text, HTML, PDF/Postscript, refer/indxbib, SQL, Tektronix 4013) can be derived from the XML source. Presumably the RFC editor would publish the XML document as the authoritative version, and would also generate and publish (from the XML) alternative copies in the ASCII text, PDF, and HTML formats. This satisfies the plain ASCII text rules bigots (in which camp I am still firmly entrenched) while taking advantage of the markup and linking facilities provided by PDF and HTML. (I've completely given up hope that Microsoft will ever acknowledge that non-flowed text/plain must be rendered with a mono-spaced font, fifty years of prior art be damned, eh?) (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) The point of XML is that you don't have to be able to read it. Given an XML DTD for RFCs, tools can be written that express the XML in pretty much any format you like. HTML would certainly be one of those formats. (And for guys like me who live and die by grep, even *I* would buy into an xmlrfcgrep program that provided grep functionality against XML-RFC-DTD files.) And all of these submission formats should be allowed if and only there's a text version to go with it. Let me go out on a limb and say No they shouldn't; only XML submissions should be allowed. Now that the shrapnel has stopped whizzing past my head, let me explain why. The traditional way of writing RFCs is with nroff, typically using a minimal subset of the -ms macros. In recent years Microsoft Word (along with other WYSIAWYG software) has invaded the traditional UNIX typesetting tools workspace to a certain degree (in the context of writing IETF-related documents). Regardless, other than the occasional Loonie who formats this stuff purely by hand, we are all already using markup languages to create these documents. That being the case, XML isn't a new way of writing these documents, it's just a different one. The current RFC DTD isn't complicated, and -- as long as it's kept simple[*] -- I don't see any excuse for people not to use it. Then again, I've been using troff exclusively for 20 years now, to the point where I can _almost_ see the consistency of its syntax ... While there isn't a whole lot I *can't* accomplish in troff, my experience with using it to write I-Ds suggests that those documents are so structured that I really just want to write a simple set of macros tailored for that task. I shudder to think what the Word crowd goes through in this regard. WYS might be WYG, but the path between the two (in my very limited experience) is one whose mana will suck the very sanity from your living soul. There is no argument to be made against the suitability of XML as the canonical format for authoring RFCs and drafts. Writing the raw XML might not be pleasant, but neither is writing raw 'roff (or MS Word) for many people. Let's embrace this as an opportunity. If we can get the marketing twits to concentrate on selling GUI XML RFC authoring tools, we just might be able to distract them from contaminating the actual working groups. --lyndon [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for.
Re: A modest proposal - allow the ID repository to hold xml
Lyndon Nerenberg wrote: Presumably the RFC editor would publish the XML document as the authoritative version, and would also generate and publish (from the XML) alternative copies in the ASCII text, PDF, and HTML formats. Ok. This would be fine. My point was that I as a user (and particularly the large groups of other users out there) are unwilling to do anything extra to read their RFCs. But if the secretariat already publishes the important formats, its fine! And all of these submission formats should be allowed if and only there's a text version to go with it. Let me go out on a limb and say No they shouldn't; only XML submissions should be allowed. Well, this would be quite good too. In fact, it would help the RFC editor automatization process as well -- and they could concentrate more on the real issues, such as talking to IANA or figure out cross references. Thinking some more... I'd *love* to have this. Anyone who opposes? [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. Extension? --Jari
Re: A modest proposal - allow the ID repository to hold xml
I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. Extension? existential ebulliently excellent engineering experienced eccentric --lyndon (egregious evening emoter)
RE: the VoIP Paradox
Hello, Because the internet is most emphatically not available in an emergency, while telephony must be in order to have a functioning emergency response. What makes you think that? In a number of cases, it has been shown that in catastrophic situations, IP has done nicely. John
Re: A modest proposal - allow the ID repository to hold xml
Lyndon Nerenberg wrote: This satisfies the plain ASCII text rules bigots (in which camp I am still firmly entrenched) while taking advantage of the markup and linking facilities provided by PDF and HTML. (I've completely given up hope that Microsoft will ever acknowledge that non-flowed text/plain must be rendered with a mono-spaced font, fifty years of prior art be damned, eh?) I'd like to include handy ERD, UML, etc... diagrams in PNG format to make the document more readable. -andy
Re: A modest proposal - allow the ID repository to hold xml
On Tue, Sep 02, 2003 at 01:52:38PM -0600, Lyndon Nerenberg wrote: You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. While I normally run in horror from all things XML, this is one of the few exceptions. XML would immediately solve a number of problems I face almost daily: - give me a list of all the documents belonging to a particular WG - for any given RFC, show me the chain of document dependencies (obsoletes, updated by, obsoleted by) that pass through this document - for any given RFC, generate a dependency graph based on the normative references in this document You have to have a structured document format to programmatically solve these sorts of problems, and XML provides that. (While I've become quite adept at searching rfc-index.txt with less, I really want something better.) May I add in the same direction ? The structure of the document allows for invoking relations between nodes, which helps for expressing elaborate search both on meta informations (WG, Author, etc.) and on content (the actual titles and text sections). You can surely look within all 'xmlly' available drafts for draft belonging to a specific WG AND referencing a list of specific docs in sections whose title contains a specific word. This would be hard to express against the txt version. And I second Ned's comments about generating *useful* diffs between document revisions. This is especially useful if we generate drafts in XML format. I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) I wonder whether this has not already been done by zvon (http://www.zvon.org/). Concerning referencing rfcs, citation libraries from http://xml.resource.org look rather complete. Several additions to the xml cause: Edition in xml allows for good modularity, e.g. with the definition of xml entities. This is an easy way to divide work between several editors. Availability of the xml source helps for editors to welcome new contributors. What I would suggest is the following: - Authors provide draft in xml XOR txt . This allows for a test period of xml as an alternate default format; authors do not provide both, this in order to avoid incoherences. - rfc editor generates txt, ps, etc. versions. html version may only require reference to a stylesheet, though this is currently tricky because few browsers actually support xml+xsl. Newcomers to xml should be informed of the following: - xml is easy. - Grammar/spelling tools compatible with html generally work (I use ispell and aspell indifferently). - Document structure and well-formedness can be validated. - Maintaining an xml source is easy, compared to maintaining a ASCII formatted txt: this is a point authors may care about. - xml rendering generates classic formats and newers: this is what reviewers, readers care about. - xml users are not hackers, extremists or ninjas. Common sense and good pratice is the main source of xml advocacy. Also, xml is not perfect; it is only better. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/
RE: Solving the right problems ...
Is the sender anonymous or could we know name and affiliation? Thanks, Henry Sinnreich MCI From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 11:10 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Solving the right problems ... Vinton, I bow to your position. We once had offices very close to each other. Remember MCI Mail? I am surprised you're back with MCI or whatever. But... Having quietly listened to what's being said, who's saying it, and where they are ... I am reading email from some good thinkers, obviously good people, not quite open source gnomes, but close. What's in it for me, or the world? Obviously IETF picks some pretty nice places to meet. And it is a pretty impressive org to work with to pretend to care about making a difference. Hey, if you're in academia and want to eat, you'd better get some corporate funding. Where do we go from here? Eating good. Unemployment bad. Well OK, what's best? What's acceptable? What keeps people employed?Bottom up? Start with the itsy-bitsy, bit-by-bit lower level protocol bits and bytes and try to complete the Tower of Babel (which by the way I think was in Iraq), or take an Alan Turing type deep thinking approach that no employing company can or will afford? (I wonder why he ate an apple spiced with cyanide?) OK. Here's the point more specifically. Considering the DEEP ISSUES people are beginning to discuss ( OK you do recognize them as deep issues right?) IETF is at a crossroad. A paradigm shift from within is not possible. Not given the funding employers. Or the controlling employers. Do you have the chutzpah or the intellectual purity to see the future beyond your next pay check? Or, is this beyond the IETF, which I suspect is the case. Or do we just wait for theTower to complete and buy a farm in Montana?
RE: Solving the right problems ...
Is the sender anonymous or could we know name and affiliation? Thanks, Henry Sinnreich MCI From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 11:10 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Solving the right problems ... Vinton, I bow to your position. We once had offices very close to each other. Remember MCI Mail? I am surprised you're back with MCI or whatever. But... Having quietly listened to what's being said, who's saying it, and where they are ... I am reading email from some good thinkers, obviously good people, not quite open source gnomes, but close. What's in it for me, or the world? Obviously IETF picks some pretty nice places to meet. And it is a pretty impressive org to work with to pretend to care about making a difference. Hey, if you're in academia and want to eat, you'd better get some corporate funding. Where do we go from here? Eating good. Unemployment bad. Well OK, what's best? What's acceptable? What keeps people employed? Bottom up? Start with the itsy-bitsy, bit-by-bit lower level protocol bits and bytes and try to complete the Tower of Babel (which by the way I think was in Iraq), or take an Alan Turing type deep thinking approach that no employing company can or will afford? (I wonder why he ate an apple spiced with cyanide?) OK. Here's the point more specifically. Considering the DEEP ISSUES people are beginning to discuss ( OK you do recognize them as deep issues right?) IETF is at a crossroad. A paradigm shift from within is not possible. Not given the funding employers. Or the controlling employers. Do you have the chutzpah or the intellectual purity to see the future beyond your next pay check? Or, is this beyond the IETF, which I suspect is the case. Or do we just wait for the Tower to complete and buy a farm in Montana?
Re: A modest proposal - allow the ID repository to hold xml
From: Lyndon Nerenberg [EMAIL PROTECTED] ... [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. I don't know about shutting down the IETF, but I do know that in this century you've stated the compelling reason to run screaming from this set of proposals. Have you looked at the 250 lines of XML cruft that Microsoft thinks are required to accompany a 1 word mail message today? Have you ever glanced at the incredibly bloated and broken HTML that most HTML mark-up tools produce? Now recall the galloping freeping creaturism of the last 3 I-Ds you've read. A Turing machine with Perl-like syntax would be incomparably simpler and cleaner than the result of the 5 years work of the new working group in the new area. (What--you don't realize that a new working group would be required?) Vernon Schryver[EMAIL PROTECTED]
Re: the VoIP Paradox
Simon; Voice over IP is paradoxically both internet and telephony at the same time. This article presents the paradox, and associated arguments. There is no paradox. The internet carries information. You should, at least, distinguish VoIP as a telephone network and the Internet telephony. There is no internet telephony... See my paper Simple Internet Phone presented at INET2000. http://www.isoc.org/inet2000/cdproceedings/4a/4a_3.htm It, for example, says: However, it is obvious that the telephone network will be replaced by the Internet, and will eventually disappear. there is IP telephony which is There is no internet telephony... there is IP telephony which is not running on the public internet. There is also VoIP on the public internet which I like to call Voice Chat. Apparently, you don't recognize the current situation, which I foresaw several years ago. Voice chat, of course, is no internet telephony. Paradoxical reguration on voice in US is a US local issue. Please cite a document, I don't find any japanese regulation that makes it any different there... Japanese telecommunication laws (available at http://law.e-gov.go.jp/cgi-bin/idxsearch.cgi) does not distinguish telephony or voice something special and the requirement on providers is same, though detailed requirements varies. In Japan, TAs to connect the Internet and POTS telephone devices are rapidly replacing the telephone network including VoIP ones. ... do they provide PSTN-level availability? In theory, yes. In practice, there is no such thing as PSTN-level availability. in an emergency / power failure? In emergency, best effort network works better than circuit swithced one, of course. As for power, have you ever used ISDN with TAs? Masataka Ohta
VoIP regulation... Japan versus USA approaches (RE: Masataka Ohta, Simon)
Masataka Ohta and/or Simon said: You should, at least, distinguish VoIP as a telephone network and the Internet telephony. In Japan, TAs to connect the Internet and POTS telephone devices are rapidly replacing the telephone network including VoIP ones. a. VoIP is telephony and should be regulated. b. VoIP is internet and should not be regulated. Why, do you think, the Internet without voice should not be regulated? It is. Paradoxical reguration on voice in US is a US local issue. Dan says: If VoIp just was a telephony service the argument of bypass shows up in FCC policy and paying into the universal fund is an argument which is looked upon with possible merit at the Fcc. Here is the first shot across the bow: ACTA submits that the providers of this software are tele- communications carriers and, as such, should be subject to FCC regulation like all telecommunications cations carriers. ACTA also submits that the FCC has the authority to regulate the Internet. This request for relief, in its entirety, is here: http://www.fcc.gov/Bureaus/Common_Carrier/Other/actapet.html Mostly I guess IETF is supposed to be technical so I'll not blather on. The language in the request for reregulation (aka relief), Is really forcefully worded that Internet is screwing the little man with a phone pretty bad. No matter how you look at it... Bypass using Internet to begin and end in the PSTN (public switched network) is different politically and tarrif wise than a packet to packet only activity. Of course, its ultra messy. What did you expect? If one member in the session is on packets, to and from a MTA, the others are on a gateway and some of it is carried on ATM leased from a phone company... even if you want to fund the Universal fund... who pays? Everybody? just because one user joined in via a GR-303 connection? Our friends at Worldcom/MCI are in trouble for burrowing traffic to and from other countries to avoid tarrifs... presumably via IP. Its crazy in that you can't argue really this is anything except common sense, possibly both from traffic eng. and economics. The whole thing is a mess. But taxation almost always is messy. I think it was Milton Freedman who suggested designing a progressive taxation scheme that doesn't hurt the economic activity is like asking for a low-pain crucifiction. Some spots for the nails maybe hurt more than others. None feel good. But instead of being smart guy here... I have a suggestion. If you want Internet to florish with the minimum of trouble(s), don't call it VoIP. Called it QoS enhanced... personal enablement services, etc. When you write documents, etc help the sales people dream up there literature... whatever. Try to get the open ended nature of SIP in there. And of course, like the excellent lead of IETF? don't use PSTN numbers if possible. the Autonomous numbers used for the Cisco phone handout was brilliant. Anything but voice. Personal broadcasting sessions. Whatever. The question of whether the universal fund is valid is a diferent argument. I suggest its a preditory activity to deny access to services by subsidizing existing system with prejidice against low earth orbiting satellite providers. I am curious how Japan does this, but the island size and density makes the whole argument different to some extent. So, how's it work under the wise rule of NHK/MTT ??? regards, Dan Sorry if its not normal IETF subject matter. Its interesting to me, anyway thanks dan
RE: A modest proposal - allow the ID repository to hold xml
From: Rosen, Brian [EMAIL PROTECTED] Are you suggesting that we would need a new working group to allow 2629 conformant xml to be optionally submitted with text to the I-D archive? Need?--I don't know. Would inevitably have?--certainly. Why? It's in the modern Tao of the IETF. I'm not proposing any new RFC. Guidelines to authors is not an RFC. 2629 is an RFC. Actually, the last time I looked RFC 3 is an RFC. There is also an I-D in the pipeline to update the classic Instructions to RFC Authors series. The xml2rfc tool, which is not the only tool around, but it's a good one, puts a 70 line style header in front of the text, but then has almost no other bloat that I can see. Is that too much? I don't think there is any cruft at all in the xml described in RFC2629. Now, to the charge that this is feeping creaturism, we must admit guilt. I think there is some value in this proposal. Many seem to agree. I don't like the idea of XML, postscript, or any other standard de jure mark-up language for standards documents, but that's not my point. The nature of modern IETF is such that those who are most enthused about XML will inevitably include many who see no other opportunity for personally Contributing To The Standards Process and perhaps getting their names into the RFC Index. They will not tolerate letting Marshall Rose alone decide what XLM features can be allowed via RFC 2629. They will point out that RFC 2629 is more than four years old and demand that it be updated to address the latest microstupid standard. They'll also point out that Informational is a weak category for something so important to the IETF. Once the camel's nose of updating RFC 2629 is in the tent, we'll have a 3 year (if we're lucky) process that will produce something that will make Microsoft's XML mail cruft look tiny, simple, and elegant. To put my point another way, if you allow XML, you will end up requiring the RFC Editor to accept the output of every mark-up tool that exists or will ever exist, regardless of the restrictinos imposed by RFC 2629. Please think what that really means. You might as well forget ASCII and declare that all future I-Ds and RFCs must be written the then current MS Word format. Vernon Schryver[EMAIL PROTECTED]
Re: A modest proposal - allow the ID repository to hold xml
On Wed, Sep 03, 2003 at 09:46:09AM -0400, Rosen, Brian wrote: What if the version of the tool the author used is different from the I-D editor? The tool itself has -in theory :)- no incidence. Only the DTD has, and it is not expected to change very often. What if the xml is not well formed and the tool does something unexpected? Well-formedness and validation against dtd MUST be checked by I-D editor, and SHOULD by authors. Note that this pb is the same with current scheme: authors can provide messy, bad formatted documents with ansi escape sequences, etc. What do we do when we upgrade the xml schema (that is, do we have to go back and edit older documents)? This is a general pb. Let's assume we change formatting rules for txt IDs. Then, how do we upgrade to new format ? As for many document formats, ascendant compatibility is a legitimate expectation, and is easily granted. When a design flaw from previous models has to be corrected, then most of the time, it should be easy to move old doc to the latest model with a batch xsl tranformation; this sometimes happens. All of these questions would have to be answered, and answered well enough to satisfy some pretty demanding people, some of whom are pretty content with the status quo. Sure. BTW, note that the xml source actually contains in the clear the content of the draft. Information can not be lost. My proposal avoids such discussions. It makes no requirements other than if xml is submitted, then it SHOULD be in conformance to 2629. In my opinion, it MUST be in conformance to 2629 DTD (or later version). If everyone designs one's own DTD, then the advantages from sharing the xml source are greatly reduced. I also think it is MUCH better to start with the I-D archive and not change the RFC process. I certainly agree. Among other things, I-Ds expire. If this change doesn't work, in 6 months, we can be rid of any vestiges. RFCs don't expire (although they get obsoleted), and the time frame is much longer. Let's stick to I-Ds only, please. Brian -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/
RE: VoIP regulation... Japan versus USA approaches (RE: Masataka Ohta, Simon)
I am curious how Japan does this, but the island size and density makes the whole argument different to some extent. So, how's it work under the wise rule of NHK/MTT ??? That'd be MPHPT at http://www.soumu.go.jp/ see http://www.itu.int/osg/spu/newslog/2003/09/03.html#a172, particularly the Japan talk (sorry Powerpoint) which explains how they're allocating telephone numbers to IP terminal devices and the policy considerations they're working on (e.g., quality, interconnection, emergency services, etc.) The uptake in VOIP in Japan has been driven by the success of cheap/fast broadband (see http://www.itu.int/osg/spu/newslog/2003/07/21.html#a72 for background explanation). In Japan, consumer broadband prices per Mbit/s are about 35 times cheaper than the US. For example, you can buy 100 Mbps of residential FTTH from USEN for about US$ 49.00 a month. Many countries have moved beyond the regulatory debates that characterize the US very-much sector-specific regulatory framework. There are a number of indications the landscape is changing rapidly in the US too (see http://www.itu.int/osg/spu/newslog/categories/voip/2003/08/22.html#a159) Bob -- Robert Shaw [EMAIL PROTECTED] ITU Internet Strategy and Policy Advisor Strategy and Policy Unit http://www.itu.int/spu/
RE: A modest proposal - allow the ID repository to hold xml
I think there are quite a few reasons. Mine are: 1) Ability to render in alternate ways to improve readability and accessibility 2) Ability to cross reference documents 3) More uniformity in, e.g. references Brian -Original Message- From: Paul Hoffman / IMC [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 1:06 PM To: Rosen, Brian; '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml At 6:15 PM -0400 8/27/03, Rosen, Brian wrote: I therefore have a modest proposal: Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft. You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. --Paul Hoffman, Director --Internet Mail Consortium
Re: A modest proposal - allow the ID repository to hold xml
I don't know about about you, Paul, but I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. and for folks who are of the xslt persusasion, julian's html output is very sweet... /mtr ps: the point being, that there's not just one tool that works with this stuff... pps: oh, and did i mention the every expanding bibliographic libraries already in 2629... the 3gpp reference set is coming up later this week (thanks miguel!)
Re: Solving the right problems ...
At 08:41 AM 9/2/2003 -0700, Dave Crocker wrote: Vint, vgc If you look at the instant messaging systems, they map a private vgc identifier space (IM name or handle) into IP addresses and vgc apparently run background heartbeat to re-assign the mapping if the vgc identifier in the heartbeat arrives in a packet with a different IP vgc address than before - I was under the impression that they did not handle mobility nearly so dynamically or automatically. Rather, I seem to need to log in whenever I move. So they seem to do a login-time mapping. (On the other hand, the login for IM is usually automatic.) no at least AIM tracks in real time In any event, I suspect that your domain name-based suggestion is the right one to pursue. That is, use DNS for the public, persistent name, and have a record that points to a dynamic address-mapping registry. (One might even think of mapping to a presence service...) Somehow, dynamic DNS does not seem like such a good idea, for anything that might change this much or this rapidly and serious host mobility. agree d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253, fax:+1.866.358.5301 Vint Cerf SVP Technology Strategy MCI 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 703 886 1690 (v806 1690) 703 886 0047 fax [EMAIL PROTECTED] www.mci.com/cerfsup
RE: A modest proposal - allow the ID repository to hold xml
The problem with nroff is that there is no RFC to reference that specifies how a document is formatted with nroff. There is wide variation in the macro packages people use to create a document with nroff. Even the RFC editor doesn't try hard to get the nroff source when editing; they make their own. I'm also trying pretty hard to keep the word modest I used in the title of this thread in mind. I'd like to try one simple thing to make I-Ds easier to read and use. Brian -Original Message- From: Zefram [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 1:56 PM To: Rosen, Brian Cc: '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml Rosen, Brian wrote: Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft. The value in this would be that it provides everyone with the document source, suitable for generating patches for the author. This is useful, but if it's going to be allowed with XML then we should also allow it with nroff, which historically we haven't. I don't have particularly strong feelings either way, but I do think these two cases should be treated equivalently. -zefram
Re: A modest proposal - allow the ID repository to hold xml
I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) actually, carl malamud and brad burdick wrote a script back in 99 that had a 20% success rate on the legacy rfcs. the (unofficial) xml versions of those rfcs is available online. steven connor did some work for me after that to produce xml versions of the remaining rfcs which excluded the middle (i.e., just the front matter and references sections got translated). so, it's not as much work as you'd think, but still far more work than i'd like... /mtr
Re: where the indirection layer belongs
Dear Keith Moore, Maybe I read your paper on project SNIPE too quickly, but it was not immediately clear that the problems you mentioned were a specific result of an attempt to make the application resilient against (sudden) changes in IP address. More specifically, it was not clear from that report that the additional complexity did come from the attempt to provide the kind of resilience we are seeking, or from the rather ambitious goals of project SNIPE. I will re-read more slowly and carefully this time. Yours sincerely, Robert Honore. Keith Moore wrote: (regarding the complexity of putting a general-purpose layer to survive address changes between L4 and L7) But why do you assert that it will take lots of complexity and overhead? Can you point to some code where they tried this? As far as I know, nobody has really given this an earnest try as yet. At least not with any IP protocols. I tried this in connection with a project called SNIPE that I worked on several years ago. SNIPE was an attempt to build a very reliable distributed computing environment that supported, among other things, the ability to access a computing resource via multiple addresses (mostly in order to exploit high-bandwidth local networks not necessarily using IP), and the ability of both hosts and processes to migrate to other addresses. It used a DNS-like service similar to RESCAP (for those who remember that) to register the addresses at which a process was accessible, and it attempted to provide TCP-like streams on top of TCP and this registry that would survive changes in those addresses. Basically I found that you can get such a service to work reasonably well and reasonably efficiently if endpoints don't move without adequate notice. OTOH if hosts or processes do move without adequate notice then you end up needing to implement the mechanisms I mentioned earlier, and that involves extra copies and extra overhead. The reason I am preposing that the two problems (changing addresses with adequate notice and changing addresses without adequate notice) be treated separately is that by trying to make a single mechanism serve both purposes you end up with a lot of inefficiency and/or cost that aren't needed in most cases. And that's true (for different reasons) regardless of whether you insert that single layer between L3 and L4 or between L4 and L7. What specific glue do you believe it requires for the L4 to L7 approach? Thought I'd said this already: buffering of data until acknowledged by the peer, generation and processing of acknowledgements, retransmission of lost messages due to broken connections, windowing (so you don't degrade to stop-and-wait), duplicate suppression. You also need to multiplex control and data information over the same stream and to probe for other addresses when you get a failure on the one you were using. How does that compare to what is needed in an L3 solution? If you work on the problem at (or just above) L3, transport protocols already have the code needed to recover from lost messages, so you don't have to reimplement that. You basically need a mechanism by which the layer can realize it needs to start routing packets differently, and do so. You probably need multiple ways that the layer can get that information because the remote address can change for a variety of reasons and in lots of different places in the network. (That's equally true for the L4-L7 layer as for the L3-L4 layer, but the L4-L7 layer isn't in a position to get some of that information. The L3-L4 layer can potentially recover from address changes more quickly but to do that safely it has to be able to authenticate and establish a basis for trust in a wider variety of information sources.) Yes you can do that but it presumes that the host knows a priori whether or not it needs the stabilization layer. I would make the mechanism used to provide stable addresses a property of the network- either the network provides reasonably stable addresses (i.e. plenty of prior notice before changing them) or it provides a stabilization layer. That way, networks that don't need it don't pay the overhead. But I would argue that the host or at least the application's designer knows whether it will need the stabilisation layer. It can't know that reliably unless the network without the stabilization layer has well-defined properties - e.g. the network won't change addresses of a network without advertising those changes with a minimum amount of advance notice. If addresses can potentially change at arbitrary times with no assurance of stability then every app needs the stabilization layer (or provide its own means of recovery). Making the mechanism that provides the stable network addresses a property of the network leaves the question of how. Even if that were achieved though, that still does not completely or effectively address the problem of one application process identifying its peer across
RE: A modest proposal - allow the ID repository to hold xml
Jari If we have xml in the archive, then there are several tools that can serve you up your choice of formats from that archive. I don't think the value of storing the html bits in the archive is all that much additional value. One could have a website that delivered such a thing without storing the html bits. Such a site would permit the hyperlinking that you are talking about. We also avoid heated discussions about what was allowable in the html, what version of which tools, etc. This is a contentious enough issue (rough consensus and running code applies, right?), and making it bigger makes it harder to reach rough consensus. Let's just do one simple thing -- allow xml, and see how it goes. Brian -Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 1:28 AM To: Michael Thomas Cc: Paul Hoffman / IMC; Rosen, Brian; '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml Michael Thomas wrote: Paul Hoffman / IMC writes: At 1:22 PM -0400 9/2/03, Rosen, Brian wrote: 2) Ability to cross reference documents That benefit only appears if all, or a significant proportion, of the Internet Drafts are in XML or a similar format. That's not what you proposed. It seems to me that a fairly simple hack could be consed up to generate HTML or whatever for current I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) And all of these submission formats should be allowed if and only there's a text version to go with it. --Jari
RE: A modest proposal - allow the ID repository to hold xml
Lyndon You make some good points. However, I have not proposed that we change the RFC process, and I've been very carefull to propose that we only accept xml optionally, retaining the requirement to 'send text'. I did so quite deliberately, and I'd really appreciate it if we could take this one small step, rather than changing the entire process, which has served us well for so long. We get a very large bang for such a small, incremental addition. Can we just try this step and see what happens? Brian -Original Message- From: Lyndon Nerenberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 5:24 AM To: Jari Arkko Cc: [EMAIL PROTECTED] Subject: Re: A modest proposal - allow the ID repository to hold xml On Wed, 3 Sep 2003, Jari Arkko wrote: I'd very much like to allow the submission of XML to the I-D directories. However, in addition I'd like to actually allow the submission of HTML, generated by xml2rfc. Why? Because I'd really like to browse most drafts through my browser, jump to sections, find the references easily etc. And without performing any extra steps by myself. One of the primary reasons for proposing XML as the canonical RFC format is that these other formats (ASCII text, HTML, PDF/Postscript, refer/indxbib, SQL, Tektronix 4013) can be derived from the XML source. Presumably the RFC editor would publish the XML document as the authoritative version, and would also generate and publish (from the XML) alternative copies in the ASCII text, PDF, and HTML formats. This satisfies the plain ASCII text rules bigots (in which camp I am still firmly entrenched) while taking advantage of the markup and linking facilities provided by PDF and HTML. (I've completely given up hope that Microsoft will ever acknowledge that non-flowed text/plain must be rendered with a mono-spaced font, fifty years of prior art be damned, eh?) (It may be that this is possible via XML as well -- I'm not expert in XML so I can't tell if its readily supported by everyone's browser without loading lots of DTDs. Does someone know?) The point of XML is that you don't have to be able to read it. Given an XML DTD for RFCs, tools can be written that express the XML in pretty much any format you like. HTML would certainly be one of those formats. (And for guys like me who live and die by grep, even *I* would buy into an xmlrfcgrep program that provided grep functionality against XML-RFC-DTD files.) And all of these submission formats should be allowed if and only there's a text version to go with it. Let me go out on a limb and say No they shouldn't; only XML submissions should be allowed. Now that the shrapnel has stopped whizzing past my head, let me explain why. The traditional way of writing RFCs is with nroff, typically using a minimal subset of the -ms macros. In recent years Microsoft Word (along with other WYSIAWYG software) has invaded the traditional UNIX typesetting tools workspace to a certain degree (in the context of writing IETF-related documents). Regardless, other than the occasional Loonie who formats this stuff purely by hand, we are all already using markup languages to create these documents. That being the case, XML isn't a new way of writing these documents, it's just a different one. The current RFC DTD isn't complicated, and -- as long as it's kept simple[*] -- I don't see any excuse for people not to use it. Then again, I've been using troff exclusively for 20 years now, to the point where I can _almost_ see the consistency of its syntax ... While there isn't a whole lot I *can't* accomplish in troff, my experience with using it to write I-Ds suggests that those documents are so structured that I really just want to write a simple set of macros tailored for that task. I shudder to think what the Word crowd goes through in this regard. WYS might be WYG, but the path between the two (in my very limited experience) is one whose mana will suck the very sanity from your living soul. There is no argument to be made against the suitability of XML as the canonical format for authoring RFCs and drafts. Writing the raw XML might not be pleasant, but neither is writing raw 'roff (or MS Word) for many people. Let's embrace this as an opportunity. If we can get the marketing twits to concentrate on selling GUI XML RFC authoring tools, we just might be able to distract them from contaminating the actual working groups. --lyndon [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. ___ This message was passed
RE: A modest proposal - allow the ID repository to hold xml
Jean-Jacques Is it not better to add xml incremental to text, rather than exclusive OR? If we demand that the I=D editor have a tool and use it to generate text, we open a large box of problems. What if the version of the tool the author used is different from the I-D editor? What if the xml is not well formed and the tool does something unexpected? What do we do when we upgrade the xml schema (that is, do we have to go back and edit older documents)? All of these questions would have to be answered, and answered well enough to satisfy some pretty demanding people, some of whom are pretty content with the status quo. My proposal avoids such discussions. It makes no requirements other than if xml is submitted, then it SHOULD be in conformance to 2629. I also think it is MUCH better to start with the I-D archive and not change the RFC process. Among other things, I-Ds expire. If this change doesn't work, in 6 months, we can be rid of any vestiges. RFCs don't expire (although they get obsoleted), and the time frame is much longer. Let's stick to I-Ds only, please. Brian -Original Message- From: Jean-Jacques Puig [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 7:47 AM To: '[EMAIL PROTECTED]' Subject: Re: A modest proposal - allow the ID repository to hold xml On Tue, Sep 02, 2003 at 01:52:38PM -0600, Lyndon Nerenberg wrote: You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability. While I normally run in horror from all things XML, this is one of the few exceptions. XML would immediately solve a number of problems I face almost daily: - give me a list of all the documents belonging to a particular WG - for any given RFC, show me the chain of document dependencies (obsoletes, updated by, obsoleted by) that pass through this document - for any given RFC, generate a dependency graph based on the normative references in this document You have to have a structured document format to programmatically solve these sorts of problems, and XML provides that. (While I've become quite adept at searching rfc-index.txt with less, I really want something better.) May I add in the same direction ? The structure of the document allows for invoking relations between nodes, which helps for expressing elaborate search both on meta informations (WG, Author, etc.) and on content (the actual titles and text sections). You can surely look within all 'xmlly' available drafts for draft belonging to a specific WG AND referencing a list of specific docs in sections whose title contains a specific word. This would be hard to express against the txt version. And I second Ned's comments about generating *useful* diffs between document revisions. This is especially useful if we generate drafts in XML format. I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) I wonder whether this has not already been done by zvon (http://www.zvon.org/). Concerning referencing rfcs, citation libraries from http://xml.resource.org look rather complete. Several additions to the xml cause: Edition in xml allows for good modularity, e.g. with the definition of xml entities. This is an easy way to divide work between several editors. Availability of the xml source helps for editors to welcome new contributors. What I would suggest is the following: - Authors provide draft in xml XOR txt . This allows for a test period of xml as an alternate default format; authors do not provide both, this in order to avoid incoherences. - rfc editor generates txt, ps, etc. versions. html version may only require reference to a stylesheet, though this is currently tricky because few browsers actually support xml+xsl. Newcomers to xml should be informed of the following: - xml is easy. - Grammar/spelling tools compatible with html generally work (I use ispell and aspell indifferently). - Document structure and well-formedness can be validated. - Maintaining an xml source is easy, compared to maintaining a ASCII formatted txt: this is a point authors may care about. - xml rendering generates classic formats and newers: this is what reviewers, readers care about. - xml users are not hackers, extremists or ninjas. Common sense and good pratice is the main source of xml advocacy. Also, xml is not perfect; it is only better. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/
RE: A modest proposal - allow the ID repository to hold xml
Vernon Are you suggesting that we would need a new working group to allow 2629 conformant xml to be optionally submitted with text to the I-D archive? Why? I'm not proposing any new RFC. Guidelines to authors is not an RFC. 2629 is an RFC. The xml2rfc tool, which is not the only tool around, but it's a good one, puts a 70 line style header in front of the text, but then has almost no other bloat that I can see. Is that too much? I don't think there is any cruft at all in the xml described in RFC2629. Now, to the charge that this is feeping creaturism, we must admit guilt. I think there is some value in this proposal. Many seem to agree. Brian -Original Message- From: Vernon Schryver [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 03, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: Re: A modest proposal - allow the ID repository to hold xml From: Lyndon Nerenberg [EMAIL PROTECTED] ... [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. I don't know about shutting down the IETF, but I do know that in this century you've stated the compelling reason to run screaming from this set of proposals. Have you looked at the 250 lines of XML cruft that Microsoft thinks are required to accompany a 1 word mail message today? Have you ever glanced at the incredibly bloated and broken HTML that most HTML mark-up tools produce? Now recall the galloping freeping creaturism of the last 3 I-Ds you've read. A Turing machine with Perl-like syntax would be incomparably simpler and cleaner than the result of the 5 years work of the new working group in the new area. (What--you don't realize that a new working group would be required?) Vernon Schryver[EMAIL PROTECTED] ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: A modest proposal - allow the ID repository to hold xml
Rosen, Brian wrote: The problem with nroff is that there is no RFC to reference that specifies how a document is formatted with nroff. RFC 2223 has an nroff example, see Appendix - RFC nroff macros and section 3. Format Rules says ms macro package. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
RE: A modest proposal - allow the ID repository to hold xml
The problem with nroff is that there is no RFC to reference that specifies how a document is formatted with nroff. There is wide variation in the macro packages people use to create a document with nroff. Even the RFC editor doesn't try hard to get the nroff source when editing; they make their own. I'm also trying pretty hard to keep the word modest I used in the title of this thread in mind. I'd like to try one simple thing to make I-Ds easier to read and use. I agree 100%. While it is nice to dream about charters being available through rsync, making official HTML versions of all RFCs available, allow submission of HTML versions of drafts, submission of drafts to the RFC Editor in XML format, requiring XML for drafts, inclusion of bitmapped graphics in documents, or any of the other things that have been proposed as additions to the original modest proposal, these sorts of broader changes are far more difficult to implement and will be far more difficult to reach consensus on. Baby steps are in order here. Let's start small and see how it goes. Ned
[Fwd: Where to start?]
-- Sheri Salami Zytrax Inc. http://www.zytrax.com mailto:[EMAIL PROTECTED] Telephone:(514)285-9088 ---BeginMessage--- Hello: I was hoping I could get some help on how to install/build a SIGTRAN stack (M2PA) on a FreeBSD machine. I have read all the tutorials on ss7 and SIGTRAN, I now know the subtle differences between the Adaptation Layer protocols. I have downloaded most of the code from www.openss7.org to a windows machine, but I dont know what to do with them. where to I start? I dont understand the openss7 code and I am not sure which files contain what. Any help would be greatly appreciated. Thanks -- Sheri Salami Zytrax Inc. http://www.zytrax.com mailto:[EMAIL PROTECTED] Telephone:(514)285-9088 ---End Message---
RE: VoIP regulation... Japan versus USA approaches (RE: Masataka Ohta, Simon)
Many countries have moved beyond the regulatory debates that characterize the US very-much sector-specific regulatory framework. There are a number of indications the landscape is changing rapidly in the US too (see http://www.itu.int/osg/spu/newslog/categories/voip/2003/08/22. html#a159) Bob you mean that current telecoms regulations are passed their sell by date anyway and serve as trade protectionism for a fast reducing minority of vested interests? Christian Christian de Larrinaga Network Brokers Ltd +44-7989-386778
RE: A modest proposal - allow the ID repository to hold xml
From: Rosen, Brian [EMAIL PROTECTED] ... about. We also avoid heated discussions about what was allowable in the html, what version of which tools, etc. This is a contentious enough issue (rough consensus and running code applies, right?), ... If that is a problem with HTML (I agree that it is), why wouldn't it be a bigger problem with XML? Replacing HT with X doesn't magically change the politics. In fact it makes them worse, because HTML is by now more stable and has better consensus reality than XML. Vernon Schryver[EMAIL PROTECTED]
Re: the VoIP Paradox
I was downtown Ottawa on the Friday, eating at a restaurant that had power, since we had none at home. (at least, when we arrived they had power...) What I noticed is that my GSM (Fido/Microcell) had very poor reception, and I frequently didn't get a signal. My conclusion - they don't have all of the transponders on generator backup, so they have less capacity during a blackout. Repeating this design for IP telephone would not be a good idea :-)
Re: the VoIP Paradox
Michael Richardson writes: I was downtown Ottawa on the Friday, eating at a restaurant that had power, since we had none at home. (at least, when we arrived they had power...) What I noticed is that my GSM (Fido/Microcell) had very poor reception, and I frequently didn't get a signal. My conclusion - they don't have all of the transponders on generator backup, so they have less capacity during a blackout. Repeating this design for IP telephone would not be a good idea :-) Actually, we're about to repeat it in a much worse way. John pointed out that IP routed around problems during these outages, but I don't think that we should too glib about how real life those tests really were wrt VoIP: voip traffic is still a tiny fraction of TDM where it counts (ie, at congestion points and especially at the slow edges). I despair that it will not be till way too late that we discover -- unsurprisingly -- that flash crowds and IP brownouts are not only possible, but to be expected. More's the pity that we have both the standards and the deployed code (RSVP) to largely avoid this disaster in the making. I think that there's some belief that this is a technical problem with RSVP (too heavy, too whatever), but I think that's a gloss: signaled QoS is just plain hard and heavy and slow and all kinds of other unpleasant things by its very nature. No technical solution is going to make it into diffserv or best effort. So we're going to have a disaster and then Congress will do what the industry couldn't... Mike
Re: names, addresses, routes
Dave, PN Well, I consider an *identifier* as something that is more or PN less intrisically bound to an identity and a *name* as something PN that merely indicates an entity, DC I had not run into this distinction before. Now that you raise the DC point, I guess I have been thinking of identifier as an intentionally DC fuzzy, general term, with name being a more specific reference. Merriam-Webster on-line defines as follows: identifier:one that identifies identify (1b): to conceive as united identify (2a): to establish the identity identity (1b): sameness in all that constitutes the objective reality of a thing Etymology: probably from Latin identidem repeatedly, contraction of idem et idem, literally, same and same My perhaps flawed understanding is that at least some epistemological texts use the term identity to denote the stable and distinguishable existence of entities. Respectively, identify is used to denote the process of establishing the previously learned and recorded identity of an entity, and identifier is used for such names that can be used to unambigously denote the identity of entities that can be identified. [My apologies if the text above is hard to parse, but it starts to be late here, and English *is* a foreign language to me.] DC I do not understand intrinsically bound, but it sounds interesting. Well, in my thinking a specific identifier is only able to denote a specific entity. That is, the relationship between an identifier and the corresponding identity should be a function, i.e., there must not be any identifiers that denote more than one entities. Typically the relationship is (or should be) bijective. DC I am used to terminology use that derives from Shoch I have no difficulty with your terminology, perhaps other than that I sometimes use the term name in a perhaps more generic sense. Furthermore, I think that a name always requires some name space where the name is defined. Most of the existing name spaces are local, or bound to a restricted context, while some are global, or usable in some fairly generic and well understood context. When using the more generic sense of the term, a name can be considered to be *bound* to an entity. Furthermore, usually names can be re-bound. Hence, only the triple context, name, bindings identifies the entity. (Alternatively, the bindings can be considered to be a part of the context.) Hence, a single name can denote different entities depending on the context (and bindings). The same applies to identifiers, of course, since I consider the category of identifier sets to be a subcategory of the category of name sets. There is one exception, though. It should not be possible to re-bind identifiers. That is, if an identifier has been created to denote a specific entity, the same identifier should not be used to denote any other entity at any other point of time. PN In other words, an identifier implies sameness and stability of PN the identified entity, while a name does not have those connotations PN to the same extent. DC I guess I need some examples to understand this. Well, as I wrote above, I think that a name can be re-bound while an identifier should not be re-bindable. Consequently, using an identifier implies that the referred entity remains the same (as long as the identifier is valid) while a name does not necessarily have this property. On the other hand, we have to remember that sameness (i.e. identity) is a semantic property, and depends on the (overall, epistemological) context. PN However, [IP addresses] PN are not end-point identifiers but identifiers for topological PN locations within the routed network. DC In trying to think about mobility, I have been finding this point DC extremely helpful. IP addresses define a point of attachment -- a DC network interface -- rather than a host interface, as we are used to DC saying. As the host interface moves, relative to network attachments, it DC needs new IP addresses. Very true. We also have to remember the reason for this, that is, the scalability limitations of the current routing technology. In a micro-mobility solution, it may make sense to use IP addresses more like topology-unrelated names, and record a route for each address separately. For example, consider Cellular IP. DC Hence a mobility mechanism needs to support end-to-end exchanges that DC may have changing IP addresses over the life of the association. I concur. Furthermore, not only (macro)mobility mechanisms but also multi-address multi-homing mechanisms. PN Now, you may be able to do rendezvous with just names, e.g., with PN domain names. And for referencing external objects, it is often much PN better to use names than identifiers. DC DC I probably need to see some examples, here, to understand your point. Rendezvous is needed for two purposes: - to allow initial connections - to resolve the loss of working addresses caused by simultaneous movement
RE: VoIP regulation... Japan versus USA approaches (RE: Masataka Ohta, Simon)
you mean that current telecoms regulations are passed their sell by date anyway and serve as trade protectionism for a fast reducing minority of vested interests? Christian No, on the contrary. For example, if it hadn't been for proactive regulatory intervention in local loop unbundling in Korea and Japan and many other regulatory measures, there wouldn't be such a dynamic broadband market in those countries nor would one see so much growth in VOIP services. You can thank the regulators and policy makers in those countries for stimulating growth and bringing lots of benefits to users... Bob
Re: the VoIP Paradox
On Wed, 3 Sep 2003, Michael Thomas wrote: Michael Richardson writes: I despair that it will not be till way too late that we discover -- unsurprisingly -- that flash crowds and IP brownouts are not only possible, but to be expected. More's the pity that we have both the standards and the deployed code (RSVP) to largely avoid this disaster in the making. This overstates things by quite a bit. RSVP is not up to the task in a very significant way. Not only is RSVP not scalable (in similar ways that affect Multicast), but even assuming those problems were solved, which is possible, even given an ideal labatory setting, RSVP does't solve the problem, RSVP is not too heavy. It doesn't work. Not even a little bit. Assuming every router in the path played RSVP, there are two show-stopper problems: It can't detect a network failure, and the path might change for other reasons, so traffic is flowing places where resources weren't reserved. For RSVP to work, every router, end to end has to use it. If ISPs used RSVP between ISPs, some provider somewhere else would be able to really screw up your network. (Just like multicast routing) RSVP was a good try, but not a production solution. I think that there's some belief that this is a technical problem with RSVP (too heavy, too whatever), but I think that's a gloss: signaled QoS is just plain hard and heavy and slow and all kinds of other unpleasant things by its very nature. No technical solution is going to make it into diffserv or best effort. So we're going to have a disaster and then Congress will do what the industry couldn't... Mike
Re: A modest proposal - allow the ID repository to hold xml
-BEGIN PGP SIGNED MESSAGE- Jari == Jari Arkko [EMAIL PROTECTED] writes: Jari I'd really like to browse most drafts through my browser, Jari jump to sections, find the references easily etc. And without Jari performing any extra steps by myself. Jari (It may be that this is possible via XML as well -- I'm Jari not expert in XML so I can't tell if its readily supported Jari by everyone's browser without loading lots of DTDs. Does Jari someone know?) Directly, maybe in some browsers. However, once the XML is there, you can be assured that someone will run xml2rfc - HTML on everything and make it available. No reason for the secretariat to burn disk space there :-) ] Out and about in Ottawa.hmmm... beer.| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1ZDlYqHRg3pndX9AQH+uAQA4AFVhCR/B2aZZHdzmBDIASBbPM1Zz1+W XLQHhH2ouzR6eIIfdzSOltjurwq+RljI3tUAuKpseI1p5HTMYhDdvUocGmO5OIZm U0BjF7elmWklB9b6B0VM5ldbXnGdU6Y96T7okStn40jxQCkOqDms6F1HpmfCEKwq YZttpSSIXKw= =O4Xe -END PGP SIGNATURE-
Re: VoIP regulation... Japan versus USA approaches (RE: Masataka Ohta, Simon)
Robert, thanks for the links. Very educational. Indeed is the ITU definition: IP telephony is used as a generic term for the transmission of voice using IP technology. IP telephony can be broadly classified as configurations using closed-bandwidth IP networks or IP networks with guaranteed fixed bandwidths and as configurations using the Internet; these latter configurations are referred to as Internet telephony. Internet Telephony another paradox. How can the public internet possibly support telephony? We have as axiomatic the edge-to-edge principle which guarantees that the person at the other end may not have UPS power supply. This is a DESIGN GOAL of the internet, hence, the paradox. Is that design goal changing? The fact of the paradox is going to lead to paradoxical situations like internet regulation for VoIP. Ohta-san wrote: There is no internet telephony... See my paper Simple Internet Phone presented at INET2000. http://www.isoc.org/inet2000/cdproceedings/4a/4a_3.htm in the paper introduction: However, it is obvious that the telephone network will be replaced by the Internet, and will eventually disappear. At that time, most of the features of VoIP protocols will become obsolete. Instead, the Simple Internet Phone is designed placing the priority in the affinity to the Internet and its architectural principles as an end-to-end, globally connected and scalable IP network. Why is this obviously true? You do not include reliable or more importantly available in your list of architectural principle of the internet, but as I pointed out in my paradox paper, available is the top principle of the telephone network. I believe that BY DESIGN the two are mutually exclusive, thus, it is a paradox to say internet telephony. later: in an emergency / power failure? In emergency, best effort network works better than circuit swithced one, of course. If the power goes out it doesn't matter! As for power, have you ever used ISDN with TAs? No. I think you are going to assume that VoIP == TAs (terminal adapters for VoIP) which is just one narrowly defined case of VoIP, so you contradict yourself. simon On Wednesday, September 3, 2003, at 11:13 AM, [EMAIL PROTECTED] wrote: I am curious how Japan does this, but the island size and density makes the whole argument different to some extent. So, how's it work under the wise rule of NHK/MTT ??? That'd be MPHPT at http://www.soumu.go.jp/ see http://www.itu.int/osg/spu/newslog/2003/09/03.html#a172, particularly the Japan talk (sorry Powerpoint) which explains how they're allocating telephone numbers to IP terminal devices and the policy considerations they're working on (e.g., quality, interconnection, emergency services, etc.) The uptake in VOIP in Japan has been driven by the success of cheap/fast broadband (see http://www.itu.int/osg/spu/newslog/2003/07/21.html#a72 for background explanation). In Japan, consumer broadband prices per Mbit/s are about 35 times cheaper than the US. For example, you can buy 100 Mbps of residential FTTH from USEN for about US$ 49.00 a month. Many countries have moved beyond the regulatory debates that characterize the US very-much sector-specific regulatory framework. There are a number of indications the landscape is changing rapidly in the US too (see http://www.itu.int/osg/spu/newslog/categories/voip/2003/08/ 22.html#a159) Bob -- Robert Shaw [EMAIL PROTECTED] ITU Internet Strategy and Policy Advisor Strategy and Policy Unit http://www.itu.int/spu/ -- simonwoodside.com -- openict.net -- 99% Devil, 1% Angel
Re: A modest proposal - allow the ID repository to hold xml
On Wednesday, September 3, 2003, at 05:23 AM, Lyndon Nerenberg wrote: [*] The critical aspect is that the DTD *must* be kept simple. If the DTD evolves into a Turing machine with Perl-like syntax we can just acknowledge that it's time to shut down the IETF and go home. I cling to the forlorn hope that people still know - and more importantly, understand - what the 'E' in IETF stands for. Write the schema in Relax NG (RNG). It's joyful, easy-to-use, XML-based schema language. :-) simon -- simonwoodside.com -- openict.net -- 99% Devil, 1% Angel
RE: A modest proposal - allow the ID repository to hold xml
From: Rosen, Brian [EMAIL PROTECTED] I think this was and html not or html, so I think that it is easier to have one additional format and see how it goes, rather than two (or three, or four) On of the advantages of xml is that it marks up things like references and authors with the function, rather than the appearance. You can much more easily generate html from xml than the other way around. Improved formatting is good, but improved cross references/author tracking/ is also good. With xml, we can get both, albeit somewhat indirectly. I think that for a small, simple step, xml is a better choice. The same things were said the last half dozen times this issue came up. After about the second or third round in about 1989, PostScript was officially sanctioned. In some ways that went worse than opponents predicted, but in other ways better. The positive view is that PostScript for RFCs died. Since then we've had at least 2 or 3 rounds of HTML is better followed by at least two rounds not counting this one for XML. It's one thing to advocate PostScript, MS Word, XML, HTML, nroff, or whatever you like for the I-D submission format. This morning some people seemed to be saying that XML should only replace nroff. I don't see the point, but then I use vi and emacs to generate nroff. If the Editor will tolerate XML, or any of a zillion other markup or fancy document formats (I designed and implemented one 20 years ago that saw significant commercial exposure), no one has standing to complain. However, by this afternoon, the consensus among reformers seems to be replacing ASCII with XML for the normative documents. Also as I predicted this morning, there is no consensus on the DTD except that it will be small, simple, wonderful for generating HTML, links, etc., and different from Marshall's. The parade of wonderful, simple, easy to use, powerful, user friendly markup tools has already begun. The talk of submitting I-Ds through a validator sounds nice, but unimpressive to anyone with real world experience with HTML validators. I write very simple HTML with vi and emacs and use the X3C validator enough to worry that they might cut me off. Still, the fact that the X3C validator is no subsitute for testing your HTML against browsers demonstrates that correctness provers are as far from the perfection claimed in advertising for markup languages as for programming languages and protocols. It is just plain ***WRONG!*** to even start to consider anything but ASCII for the official documents. As hard as it is for the unscared to believe, even XML will fade away completely and be replaced by something else even more wonderful, user friendly, easier for convicted monopolies to embrace and extend, and so forth. When that happens, there will be a new calls for reform. To put it another way, no one who is the least uncomfortable with the existing PostScript RFCs has any standing to advocate XML for official documents. That Communism or replacing ASCII RFCs didn't work before does not support the position that this time we'll get it right. Vernon Schryver[EMAIL PROTECTED]
RE: A modest proposal - allow the ID repository to holdxml
--On Wednesday, 03 September, 2003 15:34 -0600 Vernon Schryver [EMAIL PROTECTED] wrote: From: Rosen, Brian [EMAIL PROTECTED] ... On of the advantages of xml is that it marks up things like references and authors with the function, rather than the appearance. You can much more easily generate html from xml than the other way around. Improved formatting is good, but improved cross references/author tracking/ is also good. With xml, we can get both, albeit somewhat indirectly. I think that for a small, simple step, xml is a better choice. The same things were said the last half dozen times this issue came up. After about the second or third round in about 1989, PostScript was officially sanctioned. In some ways that went worse than opponents predicted, but in other ways better. The positive view is that PostScript for RFCs died. Since then we've had at least 2 or 3 rounds of HTML is better followed by at least two rounds not counting this one for XML. It's one thing to advocate PostScript, MS Word, XML, HTML, nroff, or whatever you like for the I-D submission format. This morning some people seemed to be saying that XML should only replace nroff. I don't see the point, but then I use vi ... Vernon, The proposal seems to be evolving --or a straw man is being set up with which to kill it-- and I can't tell any more whether we agree or not. So let me try to restate things a bit... (1) As an/the authoritative format, plain ASCII text, plus whatever additional format(s) the RFC Editor decides to permit to support drawings, etc., should almost certainly remain the target for the reasons you identify. And any of those additional formats should almost certainly be self-contained page description/ layout ones. I.e., although the RFC Editor might impose additional criteria, Postscript qualifies and PDF qualifies. No mark up language, be it nroff, XML, HTML, or others, ought to qualify because they require supplemental information, embedded in processors or elsewhere, to actually determine what is displaced. (2) If a group of people, such as a WG, are collaborating on the development of a document, having the working format (whatever it is) readily available would seem to be an advantage. This should not make that format authoritative, or attach any special importance or validation to it relative to other formats. Now I think that all that Brian proposed originally was that the XML format of Internet Drafts be made available when it happened to exist. Even though that might be letting the proverbial camel's nose into the tent, it strikes me as basically harmless and probably useful. Did I misunderstand him? Do we disagree about part of the above and, if so, which part? john
Re: names, addresses, routes
On woensdag, sep 3, 2003, at 17:33 Europe/Amsterdam, Dave Crocker wrote: PN Well, I consider an *identifier* as something that is more or PN less intrisically bound to an identity and a *name* as something PN that merely indicates an entity, I had not run into this distinction before. Now that you raise the point, I guess I have been thinking of identifier as an intentionally fuzzy, general term, with name being a more specific reference. Funny, I would assume the opposite. I'm sure there are truckloads of people who have the name John Smith in their passport (although I have no idea what parents called Smith are thinking when they name their poor offspring John), but unless there is a serious screwup somewhere, each passport uniquely identifies the bearer, traditionally using such distinguishing properties such as date and place of birth, height, hair and eye color and so on. I assume that these days everyone has their country's take on the social security number in there too. When we translate this to IP, we notice that there are indeed many systems with identical canonical names, but the domain name system comes to the rescue and provides us with a naming hierarchy that makes it possible to turn locally used canonical names into globally unique names. However, it's important to note that an FQDN often isn't the real name of that which is referred to, but rather a compromise between the properties that make for good names in the real world and on the net, and, of course, availability of the desired name. I don't think we have any real identifiers in IP. If there is something you want to identify, it's usually possible to find some handle to do this. A host can be identified by its fully qualified domain name or its attachment to the network, for lack of a property that really identifies a host, if something is even possible. (Think about it: which part constitutes the essence of a host, the part that you can't take away without changing its identity?) But all of this is subject to change. So we should probably be pragmatic and use existing identifying properties if they are usable, or create new ones where necessary. It seems silly to identify a host by the mathematical property of the contents of a small file on the file system, but it works very well for SSH. The same thing for the highest or lowest IP address that a box has, but BGP and OSPF seem to thrive on it. FQDNs and IP addresses make more sense but lack a property that is sometimes important: they identify something, but don't don't bring enough information about the nature of what they identify with them. Does a FQDN point to a host or a service? Does an IP address point to a point of attachment or a host? Usually we don't care, but sometimes we do. Addresses contain information about location -- typically topological location. (The possibility of geographic location gets bandies about, sometimes.) Addresses are also globally unique. Routes give directions about how to reach the entity. Routes are relative to the starting point. Everything is relative to a starting point. Globally unique just means we agree on the starting point. PN In other words, an identifier implies sameness and stability of PN the identified entity, Obviously the stability of the identifier is limited by that of the entity being identified. And an identifier is what you make it. PN while a name does not have those connotations to the same extent. Yes, names can change, but that doesn't disqualify them as identifiers automatically. PN From this point of view, IP addresses are identifiers. So what do they identify for what purpose? I have no trouble identifying my webserver by its IP address, which hasn't changed in three years. Not so much with my laptop, as its address changes several times a day. PN However, they PN are not end-point identifiers but identifiers for topological PN locations within the routed network. In other words, addresses are addresses. In trying to think about mobility, I have been finding this point extremely helpful. IP addresses define a point of attachment -- a network interface -- rather than a host interface, as we are used to saying. Do they? What is the point of attachment? The subnet or the individual address? I don't think it can be the latter (within this context) as the interface brings as much to the table as the network in this case, in IPv6 at least. (64 bit prefix learned from a router + EUI-64. Guess what the I in EUI stands for, BTW.) It's worth noting that client-side mobility is a very different problem from peer-to-peer mobility. Hence, something like MAST is entirely adequate when it is only the client that is moving around. The client can re-find the server the same way it originally did. Very good point.
RE: A modest proposal - allow the ID repository to hold xml
From: John C Klensin [EMAIL PROTECTED] ... (1) As an/the authoritative format, plain ASCII text, plus whatever additional format(s) the RFC Editor decides to permit to support drawings, etc., should almost certainly remain the target for the reasons you identify. ... (2) If a group of people, such as a WG, are collaborating on the development of a document, having the working format (whatever it is) readily available would seem to be an advantage. This should not make that format authoritative, or attach any special importance or validation to it relative to other formats. That sounds fine or at least tolerable. Now I think that all that Brian proposed originally was that the XML format of Internet Drafts be made available when it happened to exist. Even though that might be letting the proverbial camel's nose into the tent, it strikes me as basically harmless and probably useful. yes. Did I misunderstand him? Do we disagree about part of the above and, if so, which part? My possibly mistaken impression of Brian's most recent position is that he would support XML for the official documents. Regardless of his position, other people have clearly come out in favor XML for the official format. The frequently mentioned hyperlinks among documents such as for authors would be rather boring if the links are only among documents that expire after 6 months. More powerful searching among I-Ds would be useful, but the real power would be searching among RFCs. Several people have written about converting old RFCs to XML. Vernon Schryver[EMAIL PROTECTED]
Re: names, addresses, routes
Pekka, PN Merriam-Webster on-line defines as follows: uh oh. when discussion starts including dictionary definitions, it is often worth stepping back and making sure that the right issue is being discussed. I was not criticising your usage, but rather noting that it was different from mine. And that observation was only intended to be relevant as an indicator that we (the community) probably do not have sufficient commonality to our use of the terms, for this line of discussion. This being a technical discussion, we had better have some useful, technical definitions. Then we can switch to having a debate about problems and solutions. There is technical history to the terms at issue, here. However they suffer different definitions in different technical discussions. That's bad, at least until we all agree on a single set of definitions. DC I do not understand intrinsically bound, but it sounds interesting. PN Well, in my thinking a specific identifier is only able PN to denote a specific entity. That is, the relationship PN between an identifier and the corresponding identity should PN be a function, i.e., there must not be any identifiers PN that denote more than one entities. Typically the PN relationship is (or should be) bijective. Apologies, but I am still not understanding well enough, I think. By way of seeing whether I am understanding at all: Some mappings between strings and objects are by arbitrary assignment. Some have a semantic process so that the string actually can be analyzed. Calling a computer aland does not really tell you anything about it, nevermind also not telling you where it is. Calling it aland.bbn.com at least tells you something about the administrative agency that assigned the name. (It still does not tell you anything about where it is, even though you might think it does.) Also, aland is likely not to have a unique, whereas aland.bbn.com is required to be unique. (The question of uniqueness depends on context. For most computer-related assignment processes, uniqueness is required.) PN In other words, an identifier implies sameness and stability of PN the identified entity, while a name does not have those connotations PN to the same extent. DC I guess I need some examples to understand this. PN Well, as I wrote above, I think that a name can be re-bound PN while an identifier should not be re-bindable. In the Internet context. what would be an example of an identifier that cannot be re-bound? (And let me alert you to my belief that all of them can be. So when you provide your example, please anticipate that I will be likely to cite examples that show the non-rebinding feature is a matter of policy, or otherwise itself is re-bindable... In other words, all this stuff depends on precise -- and often arbitrary -- definitions and policy.) PN In a PN micro-mobility solution, it may make sense to use IP addresses more PN like topology-unrelated names, and record a route for each address PN separately. right. as you noted later in your reply, whenever we talk about mobility we need to be careful to specify scope of possible change and rate of possible change. extremes seem to demand very different solutions. DC Hence a mobility mechanism needs to support end-to-end exchanges that DC may have changing IP addresses over the life of the association. PN I concur. Furthermore, not only (macro)mobility mechanisms but PN also multi-address multi-homing mechanisms. I'm finding myself viewing multi-homing as a simple (ie, degenerate) case of mobility. PN Now, you may be able to do rendezvous with just names, e.g., with PN domain names. And for referencing external objects, it is often much PN better to use names than identifiers. PN Rendezvous is needed for two purposes: PN - to allow initial connections PN - to resolve the loss of working addresses caused by PNsimultaneous movement ack. PN As you write, the difference between client-side mobilty and P2P PN mobility lies in rendezvous. On the other hand, we also have to PN remember that more and more servers are becoming mobile, in some way PN or another (re-hosting, network re-numbering, etc). Hence, I would PN not consider these two types of mobility that different. In the long term, no. but it's worth considering a simpler solution, for the simpler case, if a) we think there will be significant benefit, and b) deferring the more difficult part does not make it harder or less likely to be solved. The mobile-client/stable-server example requires no new rendezvous mechanism and I think it covers a very, very large portion of current mobility needs. And I think that the rendezvous function needed for mutual mobility can be solved independently. So there is no real disadvantage to deferring it from the addressing problem. PN No problem here. On the other hand, if we had proper and secure PN identifiers, packet forwarding would not be an architectural PN problem, either. we probably
Re: VoIP regulation... Japan versus USA approaches (RE: Masataka Ohta,Simon)
Simon; Internet Telephony another paradox. How can the public internet possibly support telephony? We have as axiomatic the edge-to-edge principle which guarantees that the person at the other end may not have UPS power supply. This is a DESIGN GOAL of the internet, hence, the paradox. Is that design goal changing? You are talking about paradox of PSTN, then. Emergency power supply is not required directly by law. Over ISDN, emergency power supply is not required even by finer regulation and even though NTT is voluntarily supply power, it is not enough to drive an analog phone device over a TA, which is the way almost all are using ISDN. In addition, a consequence of the end-to-end (not edge-to-edge) principle is fate sharing property to maximize reliability and availability, which has nothing to do with not having UPS. The fact of the paradox is going to lead to paradoxical situations like internet regulation for VoIP. No, not at all. It is merely that some country such as US has a paradoxical regulation on voice. There is no internet telephony... See my paper Simple Internet Phone presented at INET2000. http://www.isoc.org/inet2000/cdproceedings/4a/4a_3.htm in the paper introduction: However, it is obvious that the telephone network will be replaced by the Internet, Why is this obviously true? It was obvious, if you have had enough knowledge on PSTN. See above. But, as the replacement is happening, it is even more obvious. of the features of VoIP protocols will become obsolete. Instead, the Simple Internet Phone is designed placing the priority in the affinity to the Internet and its architectural principles as an end-to-end, globally connected and scalable IP network. You do not include reliable or more importantly available in your list of architectural principle of the internet, Reliability and availability is automatically derived from the end-to-end principle. but as I pointed out in my paradox paper, available is the top principle of the telephone network. I believe that BY DESIGN the two are mutually exclusive, thus, it is a paradox to say internet telephony. By design, telephone network, violating the end-to-end principle to have central servers, is faulty. So is MGCP, which is a major cause of loss of availability of Internet telephony or VoIP network using MGCP. In emergency, best effort network works better than circuit swithced one, of course. If the power goes out it doesn't matter! See above. As for power, have you ever used ISDN with TAs? No. Have more experience with PSTN. Masataka Ohta
Re: VoIP regulation... Japan versus USA approaches (RE: Masataka Ohta,Simon)
Bob; I am curious how Japan does this, but the island size and density makes the whole argument different to some extent. So, how's it work under the wise rule of NHK/MTT ??? That'd be MPHPT at http://www.soumu.go.jp/ Though cabinet set a wise strategy, MPHPT has no idea on what is the Internet telephony and making stupid actions. However, as the actions are so delayed and are not so actively against the cabinet strategy that they are not so harmful. The uptake in VOIP in Japan has been driven by the success of cheap/fast broadband (see http://www.itu.int/osg/spu/newslog/2003/07/21.html#a72 Progress of the Internet telephony in Japan is by private ISPs, which are convinced that free long distance telephony (with additional charged (but inexpensive) service for PSTN gatewaying) is the most powerful sales promotion tool of their service. Many countries have moved beyond the regulatory debates that characterize the US very-much sector-specific regulatory framework. There are a number of indications the landscape is changing rapidly in the US too (see http://www.itu.int/osg/spu/newslog/categories/voip/2003/08/22.html#a159) Too bad. They are still talking about voice. No one can regulate individuals use VoIP over the Internet without central authority similar to NAPSTAR. The basic problem of US regulation is not that they don't regulate VoIP but that their model on universal access charge is not economically feasible. Universal access charge is to help people in sparsely populate area. So, the charge should be paid by regional providers in densely polulated area (regardless of whether the providers provide PSTN, TV or the Internet service). Can't ITU-T perform some study to let USG recognize its fault? Masataka Ohta
Re: A modest proposal - allow the ID repository to hold xml
XML may not be the solution to the entire RFC generation process but it could certainly help those of use who programmatically scrape the text based documents to extract the basic info (references, obsoletes, updates, std, bcp, fyi, yada yada yada...) A subset of the DTD containing the summary info submitted along with the RFC text could be very useful. Cheers - Original Message - From: Marshall Rose [EMAIL PROTECTED] To: Lyndon Nerenberg [EMAIL PROTECTED] Cc: Paul Hoffman / IMC [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 1:17 PM Subject: Re: A modest proposal - allow the ID repository to hold xml I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) actually, carl malamud and brad burdick wrote a script back in 99 that had a 20% success rate on the legacy rfcs. the (unofficial) xml versions of those rfcs is available online. steven connor did some work for me after that to produce xml versions of the remaining rfcs which excluded the middle (i.e., just the front matter and references sections got translated). so, it's not as much work as you'd think, but still far more work than i'd like... /mtr
Re: names, addresses, routes
Dave; This being a technical discussion, we had better have some useful, technical definitions. Technical definitions? On the problems, yes. On the terminology, no. Then we can switch to having a debate about problems and solutions. It is a useful approach to continue the debate forever. However, to solve the problem, anyone proposing a solution may use any terminology, as long as it is clearly defined. There is technical history to the terms at issue, here. However they suffer different definitions in different technical discussions. Different technology needs different definitions. We really suffer, if you try to unify them. Masataka Ohta
