Dave, Hmmmm. Someone told me once that real-time means on a time scale such that no measurable time elapses between event occurrences and their recognition. You have to allow either this definition, or one similar to it, as - relativistically speaking - "real-time" doesn't exist in anything larger than a Planck length. So I suspect the another word for real-time might be ASAP. Interestingly enough, we had a number of people talking about real-time last week in a context where real-time may be measured in hours or even days. A classic example is any sort of production schedule - media, construction, etc. Another is bulk transportation - troop movement, shipping, etc. Admittedly, in a networking context, real time is being measured over shorter and shorter time intervals. But the Area being proposed is not really about networking, is it? -- Eric --> -----Original Message----- --> From: ietf-bounces@xxxxxxxx --> [mailto:ietf-bounces@xxxxxxxx]On Behalf Of --> Dave Crocker --> Sent: Thursday, September 22, 2005 1:14 AM --> To: grenville armitage --> Cc: IETF list --> Subject: Re: Possible new Real-Time Applications and --> Infrastucture (RAI) --> Area --> --> --> --> --> > I'm not sure 'real time' is being used here in the same --> sense it might --> > be used outside IP communities, but that's a modest nit --> for now. (I liked --> > Yaakov Stein's "Interactive Services...." variant, though.) --> --> This highlights one of the points of confusion about the --> current proposal: --> the idea for the area seems to be getting defined in terms --> of some performance --> constraints, but the constraints are fuzzy, at best. --> --> Historically, the term "interactive" refers to human --> tolerances, with the most --> interesting threshholds being at 1/2-second and 2 seconds. The term --> "real-time" tends to mean sub-second, and often much faster --> than that. --> However much of the focus is on streaming, where the focus --> is on inter-packet --> jitter, rather than the amount of time it takes for the --> first packet to show --> up, or even for round-trip time. --> --> And, by the way, just what is it that makes instant message --> and presence need --> performance characteristics that are any different from --> http, DNS, or numerous --> other "interactive" protocols? --> --> All of this leads to the larger problem that the proposed --> area appears to --> desire to stovepipe integrated work on several layers. The --> one thing this is --> sure to achieve is an eventual failure to integrate with --> other uses for shared --> layers. By definition, the folks in the new area will not --> be worrying about --> cohabitation; they will focus on on the needs of their own --> set of applications. --> --> When we start having specialized applications dedicated for shared --> infrastructure, that clever hour-glass is going to lose its shape... --> --> d/ --> -- --> --> Dave Crocker --> Brandenburg InternetWorking --> +1.408.246.8253 --> dcrocker a t ... --> WE'VE MOVED to: www.bbiw.net --> --> --> _______________________________________________ --> Ietf mailing list --> Ietf@xxxxxxxx --> https://www1.ietf.org/mailman/listinfo/ietf --> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf