"Spencer Dawkins" 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 for your careful revi
Nicolas Williams 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 tend to have an
Alexey Melnikov 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 don't see
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
condition
Hi,
--On January 8, 2010 7:28:51 AM -0800 The IESG
wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'DNS SRV Resource Records for AFS '
as a Proposed Standard
This spec needs to wait on the IANA SRV registry document
(draft-iet
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 p
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
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 co
--On Thursday, January 07, 2010 11:46 -0500 Russ Housley
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 strike a bette
--On Friday, January 08, 2010 07:28:51 AM -0800 The IESG
wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'DNS SRV Resource Records for AFS '
as a Proposed Standard
I support publication of this document. It meets a need which is
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 t
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 days
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"
Cc: ; ;
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 further:
Although this preference cannot guarantee that
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
18 matches
Mail list logo
