RE: WAP and IP
At 05.30 + 00-06-26, Mohsen BANAN-Public wrote: IETF/IESG/IAB folks keep saying TCP is good enough for everything. Patrik We don't. Patrik See for example SCTP described in draft-ietf-sigtran-sctp-09.txt and Patrik applied to many applications which for example have to do with Patrik telephony signalling. The current status, state and beginning date of that example makes my point. You are extrapolating the time it takes to get consensus around a document in a working group with people stating that TCP is good enough? After 7 months of delay, caused by the IESG, ESRO was published as an RFC in Sept. 1997. There have already been enough discussions on the IETF list about ESRO. See the archives. You seem to (once again) ignore the problems with making protocols interoperate. The rest of this discussion exists in the IETF mailing list archives. - Equal access to RFC Publication Service This is not possible, as a review process is guaranteeing the quality of the work published. For the various tracks, different reviews are done. For informational (such as ESRO) the RFC-Editor is deciding whether something is good enough, and asks for input from the IESG. Issues which were discussed heavily regarding your two protocols are: - Congestion control - Ability to gateway to/from existing standards - Internationalization issues - Security See IESG note in the beginning of RFC 2524. All new protocols have to address those issues, as the experience we have with the protocols we have today gives that those issues (probably) were not addressed enough in those. Because we made that mistake once, we don't want to make the same mistake again. So, the IESG asks all people which write new protocols to address the issues above (and some others). So, regarding the protocols you have proposed, it is not the case of "better or worse than TCP", it is about "does the protocols proposed address all issues we _today_ think a new protocol have to fulfil. That doesn't say that the protocols we use today would pass if created today. We should though not swap from something bad into another thing not solving the problems we know exists. Regards, Patrik
ESRO (RE: WAP and IP)
At 05:30 26.06.2000 +, Mohsen BANAN-Public wrote: The current status, state and beginning date of that example makes my point. After 7 months of delay, caused by the IESG, ESRO was published as an RFC in Sept. 1997. History note: ESRO (RFC 2188) was delayed, as far as I remember, because of lack of response from the authors to IESG comments; this turned out to be because the author either didn't get them or didn't think/understand that a response was needed. I remember some apologies at the time, and the document was published without making the changes that the comments (some mine) had asked for. ESRO was published without significant input from the IETF community, and has some aspects that I consider rather stupid (tied to a single UDP port number (4.6.3), use of a THREE-bit transport selector (4.4.1) and total lack of discussion of congestion control), but did not face significant opposition in the IESG. It's EMSD (RFC 2524) that was considered by the IESG to be bad enough that it was labelled with an IESG warning containing sentences like "makes EMSD completely unsuitable for end-to-end use across the public Internet", and seemingly earned the IESG the permanent enmity of Mohsen Banan. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED]
Anycast and related frobs
I throw myself upon the humble mercy of the gods that I might not make a fool of myself (again) in front of the IETF. Nevertheless, here goes... As I understand it, a goal of IPv6 Anycast is to provide implicit connectivity to the "nearest" netwise instance of a given member of a group of service providers. Now, granted, this is based on an "address", not an address / port tuple, so it's more like a group of machines, than service providers, right? What work has been done to provide a "nearest service" type of implicit addressing? From what I gather, SLP is for service *discovery*, but what I'm really on about is not "what services are available", but "where can I find *this* service, closest to me?" The canonical example of this is (duh) FTP mirrors. CPAN does a pretty good job of multiplexing you to the netwise closest mirror, but it's all done relatively heuristically, if I understand it correctly, and it's done from the CPAN main server side, which means it can't tune the response for *you* in particular. Is there work underway to "canonicalize" such discovery procedures and formalize them into, perhaps, a "Services: Optimization of Reachability to Those Available" (SORTA)? This next bit, please generalize as much as possible. FTP is what I'm thinking of this instant, because it's what triggered the thoughts, but I wouldn't want to shoe-horn a perfectly non-crappy idea into one application alone. Also, note that my thoughts on implementation might suck, so feel free to "improve" them in the inimitable IETF way. What I'm thinking of is something in which a client (say, FTP) is given a list of, e.g., URLs of available instances of the *particular* service (that is, mirrors that actually contain the data you seek). Thus, a list of hostnames and ports, and, implicit in the protocol field of the URL, a protocol intended to be used for the actual desired exchange. The client then plugs all of this into the SORTA mechanism, which queries an upstream SORTA cache, asking it for the nearest, fastest "match" out of that set, based a loose characterization of that service. So, for instance, the SORTA cache might know (based on statistics collected over time) that the mirror at foo.example.com is close to me and very fast for small FTP transactions, but unstable over time. It might furthermore know that bar.example.com is slower, but very stable, so it's better for big files. Based on that knowledge, and the list of potential candidates I gave it, it would respond with foo.example.com for a small file, and bar.example.com for a large file. Of course, that's not to say that an implementation has to be this complex. An upstream cache may pick one at random :) Or it may pick one solely based on ping times. And so on... Some reasons I'm thinking along these lines are: - ping / traceroute routinely get dumped on the floor by congested routers and picky firewalls - having every single client determine reachability to the entire mirror list is a huge duplication of effort and waste of b/w - having the server side determine reachability heuristically is a guessing game, possibly educated (no offense to the CPAN folk) I'm aware that FreeNet might provide much of this functionality implicitly in its core architecture, but I've not yet looked into it too deeply. SORTA also seems like a sort of (no pun intended) "reverse" approach to things like Harvest (and, I suppose, FreeNet). Both Harvest and FreeNet, as I understand it, look to bring the content closer to frequent requestors of it. SORTA would take a less dynamic approach. Content would stay where it is, but clients would be routed to the best instance. Actually, that's not entirely true. Content *could* stay where it is, or it could move, provided the master lists remained up to date (or there was a mechanism for propagating changes throughout the SORTA cachespace). In fact, SORTA could work together with the mirroring tools themselves to move content to near mirrors based on SORTA caching information. Which then *would* be like FreeNet :) Whee! I'm also aware that there are "global load-balancing" tricks for doing this. However, they require that you be in collusion with all mirror instances, more or less. What I'm looking for is something that could easily be joined / left by mirror members simply by adding / removing entries from the master mirror list handed to a client. Thanks for listening! -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- Me: "That was pretty gross, Andy. I can't believe you ate it after I stuck it up your nose." Andy: "It was a big grape and a small nose. It didn't get very far." - outtake from perspex imageworks, inc., design meeting, circa 1994
Re: Anycast and related frobs
From: Tripp Lilley [EMAIL PROTECTED] Subject: Anycast and related frobs Date: Mon, 26 Jun 2000 07:43:03 + (/etc/localtime) Tripp, I throw myself upon the humble mercy of the gods that I might not make a fool of myself (again) in front of the IETF. Nevertheless, here goes... As I understand it, a goal of IPv6 Anycast is to provide implicit connectivity to the "nearest" netwise instance of a given member of a group of service providers. Now, granted, this is based on an "address", not an address / port tuple, so it's more like a group of machines, than service providers, right? What work has been done to provide a "nearest service" type of implicit addressing? From what I gather, SLP is for service *discovery*, but what I'm really on about is not "what services are available", but "where can I find *this* service, closest to me?" At the 46th IETF in Washington there was a Anycast BOF, chaired by Steve Deering. In there where a few presentations on diffrent aspects of anycast. Then, when the question was raised to the floor on weither there was a need to form a anycast group few hands where raised. The conclusion was that the real need of Anycast was limited (i.e. DNS, PIM RPs and possibly a few other services) and that no specific architecture where needed. Whatever needed was allready there or few trimmings where required. For instance was UUNETs usage of Anycast for PIM Rendez-vous Points presented. They used a trick which seems to be accepted as the only thing really required to acheive the anycast service. They uses an unicast IP address which they set common for all the RPs that so require, then they insert this IP address into the normal unicast routing and the routing will find the "best" path. While it migth be a bit confusing that it is actually diffrent physical positions this is really not diffrent than having a multihomed box having access to widely separated network segments. Mr. Ohta presented the usage of Anycast in DNS root server handling over multiple ASs. The GIA proposal was a proposal for a complete anycast architecture according to the ideas as presented with IPv6. Anyway, you check these presentations and the report from the meeting in case you have not yeat done so. So, there is even some form of Anycast support in IPv4. I am sure that Mr. Deering, Mr. Alvestrand and Mr. Ohta can contribute further on this issue if so required. Cheers, Magnus
Re: Seeking Open Mobile Messaging Protocols -- Efficient E-Mail
Existing SMTP/IMAP/TCP technology is not well suited for mobile and wireless environments where bandwidth and capacity are always limited and precious. ahhh yes. that 640k video buffer again. historically every time we have made a large kludge to save bits we have looked very stupid in far less time than we ever imagined. and yes, i understand the bandwidth issue. randy
Re: Seeking Open Mobile Messaging Protocols -- Efficient E-Mail
From: Mohsen BANAN-Public [EMAIL PROTECTED] Existing SMTP/IMAP/TCP technology is not well suited for mobile and wireless environments where bandwidth and capacity are always limited and precious. More efficient protocols are needed to address the new reality of mobile and wireless networks. I am seeking open protocols which are better suited to address the requirements of mobile and wireless networks. we are in agreement so far. however I would say that the new protocols need to operate effectively not only in a mobile/wireless network, but also in a wired network, or in a mixed network that consists of both wireless and wired links. The key functional requirements for the protocols that I am seeking are: - Provide for the submission and delivery of short (4 kilobytes or less) Internet e-mail messages with the same level of functionality (or higher) that the existing SMTP protocols provide. - Provide the same (or better) level of reliability and security that the existing SMTP protocols provide. - Make reasonable trade-offs between specification complexity, implementation complexity, extendibility, scalability and efficiency. - Provide the required efficiency characteristics. These include: minimizing the number of transmissions, minimizing the number of bytes transmitted, minimizing the latency of message submission and delivery. let me suggest a few additional requirements: - high degree of functional compatibility with existing mail protocols (SMTP/MIME/POP/IMAP) so that there is not a lot of information lost when mail is gatewayed between the two environments; also so that I18N is supported in a way compatible with existing standards. - congestion avoidance that competes fairly with TCP - ability to resist denial-of-service attacks that attempt to consume server connection/session state (similar to SYN flooding attacks) Keith
Address Book Problem....
Hello Friends, I need some help desperately. I want to develop an application in which I have to present the user with the facility of using his address book, which is actually present on the desktop, to be exported to a database present on the server. For this thing to take place seamlessly, I have to present the user with a Html page having one button for opening a File open dialog box. This button will be used by the user to open the dialog , where he will click the file containing his address book. Then on selection of the file, all the addresses in his book should be populated on the Html form in a list box . Then he can select any of his addresses with the help of checkboxes and send it to the server database . I know that this thing calls for using the API for peculiar commands of the Browsers' address book application and I want to know the source of such documentation for both the Netscape browsers and also the IE. Will any of u please give me vital information in this regard ? Thank u and waiting for your replies in earnest. Sunil.
Re: IEPG Meeting - IP Addressing
On Sun, 25 Jun 2000 08:01:03 PDT, [EMAIL PROTECTED] said: IPv4 is running out of space but IPv6 is too much overhead. You'd get a lot more usable response if you explained WHY you felt IPv6 is too much overhead. Often, the complaint is (for example) "It takes too long to send a packet on a modem/PPP link", but they didn't have any IPv6 header compression enabled, or some similar problem. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
RE: WAP and IP
Vernon Schryver writes -Original Message- From: Mohsen BANAN-Public [EMAIL PROTECTED] ... There is a genuine need for a reliable efficient transport that accommodates *short* and *occasional* exchanges. There are many occasions where UDP is too little and TCP is too much. I've often heard that from telephant advocates, but I've never seen anything plausible from them. See, my friend, if you call any one who doesn't agree with your views on TCP/IP with names like "telephant advocate", reasoning is not going to convince you. It is like convincing a life long republican to vote for Al Gore - he/she has already closed the door to make sure that nothing can come in. Mohsen may be accused of any thing, but calling Mohsen whose aim is to create an open alternative to WAP is hilarious. And, Mohsen at least understands the issues involved in wireless cellular communication, something that can be said of many other TCP/IP for every thing advocates. Cheers, --brijesh (personal opinions only)
RE: WAP and IP
I apologize for this and my previous messages. I didn't realize I was talking to members of the IPv8 Brigade. From: "Brijesh Kumar" [EMAIL PROTECTED] ... Mohsen may be accused of any thing, but calling Mohsen whose aim is to create an open alternative to WAP is hilarious. And, Mohsen at least understands the issues involved in wireless cellular communication, something that can be said of many other TCP/IP for every thing advocates. There's plenty of hilarity to go around in any discussion where people are - insisting that a protocol is patent free without bothering to do a patent search for all of the ideas used in the protocol. Never mind the mysterious ways that patents can appear, or the enormous joke in the notion of being able to predict what the patent system might consider a patentable idea. - claiming that Mohsen BANAN's protocols are more open than those of WAP despite their editorial history. - persistently, unbendingly claiming that 14000 bit/sec is a bit rate that is radically lower than anything ever before used for TCP/IP. - claiming that the current and prospective webphone screens and keybaords could be useful for anything that might need even 140 bit/sec. Anyone who has tried to use those silly screens, keyboards, and thumb wheels merely to configure a phone or use a built-in directory (and isn't a telephant salescritter) must laugh at that the image of surfing the web, getting directions, buying anything other than air time, or doing anything you couldn't do just as well with an analog cell phone everywhere on earth that WAP will be available. - claiming that the IETF or any other standards committee could, even if it wanted, prevent or slow the adoption of genuinely better protocols. - demanding that "access" to the IETF publishing process be openned. Everyone who advocates keeping the RFC press open to any except official products of working groups should read Mohsen BANAN's RFC's and draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-08.txt It's not enough to talk about keeping the IETF open. You must look at the concrete consequences of the current implementation of openness. A press that tries to publish absolutely everything soon becomes a vanity press that publishes nothing read by anyone except its author. Editing is not only about suggesting fixes for spelling errors. An editor that rarely rejects a manuscript isn't. An open standards organization without real technical editing, including a lot of rejections with prejudice, is in the end not open to anything except lunatic adovcacy. We all, including the IPv8 Brigade, would be better served if the IETF left electronic vanity publishing to the world wide web, and only published official products of working groups of "legacy programmers." If no working group will adopt a draft or even form to adopt a draft, then the idea is bad or the IETF is dead, and in either case, the IETF should not publish it. As someone says, openness to good ideas does not involve opening your skull and letting your brain fall out. Vernon Schryver[EMAIL PROTECTED]
RE: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)
I certainly hope you're joking. If not, I can say definitively that this is certainly not Teledesic's view of the world. Teledesic (and it's sister network ICO) are being designed to be great platforms for carrying IP. (That means they will also be able to do WAP, but that is hardly the focus.) http://www.teledesic.com http://www.ico.com - dan -- Daniel Kohn mailto:[EMAIL PROTECTED] tel:+1-425-602-6222 http://www.dankohn.com -Original Message- From: Taylor, Johnny [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 2000-06-21 08:48 To: Donald E. Eastlake 3rd; [EMAIL PROTECTED] Subject: RE: IP over MIME (was Re: WAP Is A Trap -- Reject WAP) All, I have seen a lot of different people bash WAP over the past two days. However, I am a firm believer that WAP will become what IP is to us today. When you relate the technologies of today and the future technologies from a Telecommunication stand point. Then you will find IP is on the rise today and various Platforms are integrating or converging IP to their core networks. But when you equate the moves that are taking place for future solutions to the commercial or residential market. such as The Teledesic Model or AOL or Manasamen; then you began to get a glimpse of the future of WAP. Therefore I think it becomes quite important for this group to keep WAP as one of the main protocols of discussion / solutions. That's my take on WAP! Coming from the Brain! JT -Original Message- From: Donald E. Eastlake 3rd [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 21, 2000 7:31 AM To: [EMAIL PROTECTED] Subject: IP over MIME (was Re: WAP Is A Trap -- Reject WAP) See ftp://ftp.ietf.org//internet-drafts/draft-eastlake-ip-mime-03.txt. Donald From: Magnus Danielson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Date: Wed, 21 Jun 2000 10:40:40 +0200 From: Masataka Ohta [EMAIL PROTECTED] Subject: Re: WAP Is A Trap -- Reject WAP Date: Wed, 21 Jun 0 5:42:32 JST Phil; IP over NAT is, in no way, end-to-end. WAP and IP over NAT are equally bad. I think you're overstating your case. Yes, IP over NAT is bad, but it's nowhere near as bad as WAP. If you think so, don't say "end-to-end". If you want, it is still possible to "reconstruct" a true end-to-end IP service by tunneling it through a NAT with something vaguely resembling mobile IP. You can have IP over HTTP, IP over XML or IP over WAP equally easily. With IP over MIME you could even establish an IP connection over a mail gateway, firewall bypassing... Hmm the same goes for http proxies. The problem, however, is that the reconstruction point is an intelligent gateway which violates the end to end principle. Havent we learned to love and hate these breaking of layering? You can put basically anything over anything else when it comes to just moving bits around. While doing this we get the additional benefits of increased propagation delay, increased overhead, often complexer solutions and a new bag of problems in the interworking area. Lovely. We can feed a lot of research and engineer mouths this way. Now, while NAT and WAP both intend to solve some problems, they provide ground for new problems which naturally require new solutions. We should really ask weither some of these problems really should be solved within that scope or not. If IP over WAP is a bag of worms, maybe one should bypass WAP alltogether. Where we know that neither ATM, IP or NAT solves all the problems neither will WAP. It is not really what you could do as what you should do. Naturally there is allways politically and technical preferences which prohibits some solutions. Cheers, Magnus
