--On Friday, 13 August, 2004 11:33 -0400 "Eric A. Hall"
<[EMAIL PROTECTED]> wrote:
>...
> Suggestions about parameters has come up before (John Klensin
> suggested it to me a couple of months ago). Unfortunately,
> these kind of helper tags attempt to define content rules
> rather than transfer
On Thu, 12 Aug 2004 17:18:19 EDT, Tony Hansen said:
> The information about the mbox format being anecdotally defined is
> incorrect. The mbox format has traditionally been documented in the
> binmail(1) or mail.local(8) man pages (BSD UNIX derivatives) or mail(1)
> man page (UNIX System 3/5/III
> > A definitive authoritative specification for all variations of the
> > mbox database format is explicitly not the objective, for several
> > reasons.
> that's fine. I fully support registering application/mbox as a media
> type.
> > For
> > one thing, such a definition is outside the IETF's
> A definitive authoritative specification for all variations of the
> mbox database format is explicitly not the objective, for several
> reasons.
that's fine. I fully support registering application/mbox as a media
type.
> For
> one thing, such a definition is outside the IETF's purview, the
Bob,
I am interested in learning about any and all production use of the RSVP protocol. I
am also interested in RSVP-TE. I am especially interested in learning the experiences
of any organization which has deployed the RSVP protocol in production environments. I
am interested in how well it per
Dean Anderson wrote:
> RSVP is a idea that doesn't cut the mustard in the real world. There are
> several show-stopper problems with RSVP.
Propagating clueless FUD does not result in progress.
>
> 1) somewhat like multicast, anyone using RSVP is vulnerable to others
> mis-using or mis-configuri
Keith Moore <[EMAIL PROTECTED]> wrote on Thu, 12 Aug 2004 08:45:24 -0400:
> this is an application for a media-type. it's not trying to define the
> mbox format, it's just trying to define a label for the mbox format
> that can be used in contexts where MIME media-type labels are required.
That'
Hi Ping,
My apologies (to all) for making the same point later in the
thread that you had already made here...processing my list of
open mail in the wrong order evidently!
But I am glad to have your confirmation of the wide deployment
of RSVP-TE in carrier MPLS nets. I worked hard to promote tha
Hi,
Were Eric's question and Dean's answer limited to RSVP strictly,
or would RSVP-TE deployments be of interest? If the latter, then
what about emerging deployments of architectures that use RSVP-TE,
such as MPLS, GMPLS, and ASON? (Or are none of the news releases
true? ;-)
Cordially,
BobN
--
Dean Anderson wrote:
RSVP is a idea that doesn't cut the mustard in the real world. There are
several show-stopper problems with RSVP.
1) somewhat like multicast, anyone using RSVP is vulnerable to others
mis-using or mis-configuring RSVP. ISPs several AS's away can really screw
up things for other
> Of course. Then why this wasn't the first thing NSIS did after going
> for on-path signalling, or didn't I just manage to find it?
NSIS was specifically charged to by the Transport ADs to work on on-path signaling.
There is an analysis document being reviewed by the IESG right now ...
> I r
Dean,
Just limiting my reply to one point:
>That relegates RSVP to the enterprise Lan, where it usually isn't
needed.
>Remember, RSVP is only useful if you have a congestion problem and
need to
>choose which packets to discard. If you have no congestion problem,
then
>you have no need of RS
12 matches
Mail list logo
