Spencer Dawkins spen...@wonderhamster.org writes:
Summary: This document is almost ready for publication as a Proposed
Standard. I did have one minor question about 13.3 (in my LATE
review), but it should not be difficult to resolve, if an AD agrees
with my question.
Hi Spencer. Thank you
Nicolas Williams nicolas.willi...@sun.com writes:
In particular, the current consensus of the SASL community appears to
be that SASL security layers (i.e., confidentiality and integrity
protection of application data after authentication) are too complex
and, since SASL applications
Alexey Melnikov alexey.melni...@isode.com writes:
The I-D says:
The original
GSS-API-SASL mechanism bridge was specified by [RFC], now
[RFC4752]; we shall sometimes refer to the original bridge as GS1 in
this document.
I
With regard to this proposed WG, I have some comments on the sentences at
its beginning:
According to reports from developers of Internet audio applications and
operators of Internet audio services, there are no standardized,
high-quality audio codecs that meet all of the following three
Hi,
--On January 8, 2010 7:28:51 AM -0800 The IESG iesg-secret...@ietf.org
wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'DNS SRV Resource Records for AFS '
draft-allbery-afs-srv-records-03.txt as a Proposed Standard
This spec
Hi Christian,
Then perhaps it is good to specify that this WG is not going to look to
narrowband and wideband but only to Superwideband and Fullband. That could
be specified in that paragraph. The name IWAC (Internet Wideband Audio Codec
(codec)) could be misleading if wideband is not going to be
Greetings All and Happy New Year,
With the new year comes the RFC Editor production and publisher
function transition from USC/ISI to AMS as the new RFC Production
Center and RFC Publisher.
ISI and AMS have been working diligently behind the scenes to make
this transition process as seamless as
What do you mean by this is work we have done before? At least it has
never been the case in IETF, if that was the case why were there all these
discussions that IETF do not have the expertise to do that work?
There have been some activities to rubberstamp some codecs (iLBC, Speex
following some
Dear Herve,
According to reports from developers of Internet audio applications
and
operators of Internet audio services, there are no standardized,
high-quality audio codecs that meet all of the following three
conditions:
1. Are optimized for use in interactive Internet applications.
2.
Herve Taddei wrote:
What do you mean by this is work we have done before? At least it has
never been the case in IETF, if that was the case why were there all these
discussions that IETF do not have the expertise to do that work?
There have been some activities to rubberstamp some codecs
--On Thursday, January 07, 2010 11:46 -0500 Russ Housley
hous...@vigilsec.com wrote:
...
I do not think that anyone wants the outcome to be yet another
encumbered codec. I think these words are trying to say what
you want, but they are also trying to be realistic.
Does the following text
--On Friday, January 08, 2010 07:28:51 AM -0800 The IESG
iesg-secret...@ietf.org wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'DNS SRV Resource Records for AFS '
draft-allbery-afs-srv-records-03.txt as a Proposed Standard
I
Subject: RE: [codec] WG Review: Internet Wideband Audio Codec (codec) Date:
Fri, Jan 08, 2010 at 04:40:05PM +0100 Quoting Herve Taddei
(herve.tad...@huawei.com):
I think it was already pointed out a few times (at least see email from
Ingemar Johannson in November 2009), that this part needs to
The IESG approved publication of this document, and then the RFC Editor
noticed that it should have been approved as a BCP not a Proposed
Standard. If you have any concerns with this document being published as
a BCP, please send a message stating your reasons to i...@ietf.org in the
next few
Good improvement. I'd go a slide bit further:
Although this preference cannot guarantee that the working
group will produce an unencumbered codec, the working group shall
follow BCP 79, and adhere to the spirit of BCP 79. The working
group cannot explicitly rule out the possibility
adapting or adopting?
- Original Message -
From: Russ Housley hous...@vigilsec.com
Cc: co...@ietf.org; ietf@ietf.org; i...@ietf.org
Sent: Friday, January 08, 2010 11:14 PM
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Good improvement. I'd go a slide bit
I would have guessed adopting (nice catch. I missed it completely). but
other than this, I wanted to say that Russ's new formula seemed more in
synch with what I've been seeing on this list - much stronger than will
try (would be nice).
Thanks,
Spencer
- Original Message -
From:
I like that.
On 2010-01-08 18:14, Russ Housley wrote:
Good improvement. I'd go a slide bit further:
Although this preference cannot guarantee that the working
group will produce an unencumbered codec, the working group shall
follow BCP 79, and adhere to the spirit of BCP 79. The working
group
The IESG has received a request from an individual submitter to consider
the following document:
- 'DNS SRV Resource Records for AFS '
draft-allbery-afs-srv-records-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG approved publication of this document, and then the RFC Editor
noticed that it should have been approved as a BCP not a Proposed
Standard. If you have any concerns with this document being published as
a BCP, please send a message stating your reasons to i...@ietf.org in the
next few
20 matches
Mail list logo
