Mans Nilsson writes:
But we are not running out of proposals for codecs to adapt. Both CELT
and SILK seem reasonable.
Speaking for me as a user, MP3 and AAC are at least worthy of
consideration. Someone said on this list that they waste bandwidth, but
VoIP's main problem for me as a user is
At 06:08 04-01-2010, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Nameservers for IPv4 and IPv6 Reverse Zones '
draft-jabley-reverse-servers-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few
At 00:50 05/01/2010, John R. Levine wrote:
For the sink.arpa, it would be good to explain why we want this name to
exist.
We *don't* want the name to exist; that's the point of the draft. I
presume that's what you meant?
It would still be nice to put in an explanation of the motivation
for
On the table at 2.1.4 you need to add LATNIC that seems to be also
reserved by ICANN, not sure why they missed it on the DAG but it's on
every single Registry Agreement.
For 2.2.4, I believe all the names listed in 2.1.4 are also reserved
for second level domains and you are still missing a place
Yeah. As far as I know, it is quite uncommon for applications to hard code
treatment of .INVALID. But you seem to be saying that they do, and that
causes problems that SINK.ARPA would solve. Tell us what they are.
There is one case where knowledge and special handling of the name may
cause
These are reasonable things to add, but I'm waiting to see if there's
agreement that it's worth moving forward.
On the table at 2.1.4 you need to add LATNIC that seems to be also
reserved by ICANN, not sure why they missed it on the DAG but it's on
every single Registry Agreement.
You're
Hi,
On 2010-01-05, at 03:34, SM wrote:
Is what is proposed in this draft a matter of interest to the DNS Operations
Working Group? If so, the document could have been brought to the attention
of the relevant working group before the Last Call. That doesn't preclude
the draft from being
Catering to the backwards compatibility needs of qam v.34bis doesn't
seem like a terribly high priority application for a wideband voice
codec... Your user agent can just use g.711 for that application.
Richard Shockey wrote:
Just as an amusing side bar to the discussion ..you all know that any
I think CELT and SILK are both great codecs.. I was under the impression that
SILK ran at 32kHz and did internal resampling but that doesn't appear to be the
case. Either way we have six sample rates to pick from between the two codecs
giving you bandwidth vs quality options that really do fit
Is the source and spec for the SPIRIT codec out there? I would be interested
in trying this out in FreeSWITCH... I'm a codec whore... if you haven't
noticed. :P
/b
On Jan 4, 2010, at 4:29 PM, Jean-Marc Valin wrote:
The one you misses is SPIRIT's IP-MR codec. As you say, with the four
I can see the motivation to pay big bucks for video codecs. Using
Mpeg4 can reduce your bandwidth costs and save real money. I can see
why there was a big incentive to save money on audio codecs in the
1990s.
At this point an audio codec is going to have to save a huge amount ot
bandwidth to be
On 2010-01-04 at 06:08 -0800, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Nameservers for IPv4 and IPv6 Reverse Zones '
draft-jabley-reverse-servers-01.txt as a Proposed Standard
First an editorial nit, there's an
Brian West wrote:
I think CELT and SILK are both great codecs.. I was under the impression
that SILK ran at 32kHz and did internal resampling but that doesn't
appear to be the case. Either way we have six sample rates to pick from
between the two codecs giving you bandwidth vs quality options
Hi,
I do not think that the IETF should accept any work because people want to
do it, if this is the case a group of people can come and ask to start
working on any idea they have that has some relation to the Internet. IETF
should accept work that is in scope for of the IETF and for which there
I can see the motivation to pay big bucks for video codecs. Using
Mpeg4 can reduce your bandwidth costs and save real money. I can see
why there was a big incentive to save money on audio codecs in the
1990s.
At this point an audio codec is going to have to save a huge amount ot
At 05:39 05-01-2010, Jorge Amodio wrote:
On the table at 2.1.4 you need to add LATNIC that seems to be also
reserved by ICANN, not sure why they missed it on the DAG but it's on
every single Registry Agreement.
PSO might also have to be added then. According to information
published by IANA,
On Jan 5, 2010, at 11:47 AM, Richard Shockey wrote:
At this point an audio codec is going to have to save a huge amount
ot
bandwidth to be worth the hassle, let alone the cost of using
encumbered technology.
Its not about the bandwidth. Its about the quality of the voice in
occasionally
Roni Even said:
I do not think that the IETF should accept any work because people want to
do it, if this is the case a group of people can come and ask to start
working on any idea they have that has some relation to the Internet. IETF
should accept work that is in scope for of the IETF and
Roni == Roni Even ron.even@gmail.com writes:
Roni Hi, I do not think that the IETF should accept any work
Roni because people want to do it, if this is the case a group of
Roni people can come and ask to start working on any idea they have
Roni that has some relation to the
Marshall Rose has lead the development effort for xml2rfc for many
years. Many thanks to him and the other folks that have offered their
help as well. As you can see from the message below, Marshall is ready
to pass the reigns to another volunteer. If another volunterr is not
found, then
Olafur == Olafur Gudmundsson o...@ogud.com writes:
Olafur There is one case where knowledge and special handling of
Olafur the name may cause problems: DNS Liers i.e. specialized
Olafur DNS resolvers that make all non-existing name exist that do
Olafur not generate lie for
Hi Joe,
At 08:00 05-01-2010, Joe Abley wrote:
We think the re-delegation of IN-ADDR.ARPA and IP6.ARPA is of great
interest to dnsop and other operational forums outside the IETF, and
as I mentioned yesterday the redelegation
I apologize for the working group question. I forgot that the draft
+1
On 5 Jan 2010 Patrik Falstrom wrote:
I agree with this.
On 4 jan 2010, at 23.40, Sam Hartman wrote:
I've been thinking about the codec issue for a while. I think it is
really desirable for the IETF to charter this group. I don't think the
charter should prohibit the working
On 1/4/10 5:39 PM, Brian West wrote:
Is the source and spec for the SPIRIT codec out there?
http://tools.ietf.org/html/draft-spiritdsp-ipmr-00
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
On 1/5/10 11:10 AM, Roni Even wrote:
Hi,
I do not think that the IETF should accept any work because people want to
do it, if this is the case a group of people can come and ask to start
working on any idea they have that has some relation to the Internet. IETF
should accept work that is in
On 2010-01-05, at 16:55, SM wrote:
The diversity of operators has some advantages, i.e. not sharing fate. The
Introduction Section of this draft mentions that The choice of operators for
individual nameservers is beyond the scope of this document. I don't know
whether a change of
26 matches
Mail list logo
