search for: ietf

...the FLAC specification through the Internet Engineering Task Force. I'm working with MediaArea on the PREFORMA project which focuses on building conformance checkers for Matroska and FFV1. Since Matroska and FFV1 are not yet formally standardized, this past July, I presented a proposal for an IETF working group for standardizing specifications for FFV1 and Matroska, both of which are open-source but without formal standardized specifications. We chose to bring this to the IETF because of relevant past/ongoing work in the IETF(including the netvc working group's Thor codec and Daala, and...

Hi Jean-Marc, Alfred and Greg, Are you receiving the mails from IETF about draft-ietf-avt-rtp-speex The mails are not coming from AVT mailing list, but I think we are all 3 part of a minimal list (draft-ietf-avt-rtp-speex at tools.ietf.org) dedicated to latest discussion about the draft. I have answered some questions, but there are small changes and adaptation st...

...an-Marc Valin wrote: > Hi Aymeric, > > Yes, I'm receiving the emails but haven't had enough time to look into > the details yet. I've seen you responded to many comments, so what are > the ones for which we still need to respond? Summary is there: https://datatracker.ietf.org/idtracker/ballot/2837/ As I understand: we need to change "mode" definition to be ONLY a list of comma separated values. This is because order of several modes has no importance according to another rfc about SDP... We need a few adjustment: * cng and vbr should be optionnal t...

...$ the first number in my prompt is the return code of the last command; note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it returns 0. at the least, it should return non-zero on failure. I note that the relevant RFC doesn''t include an enumeration for ECDSA: https://tools.ietf.org/html/rfc4255#section-3.1.1 Could anyone on this list kick off the IETF process for allocating a new ID in that registry for ECDSA? I''m not currently involved in the IETF''s Network Working Group so i don''t really know the political landscape there. Regards, --dkg...

-------- Original-Nachricht -------- Betreff: [87all] IETF 87 Technical Plenary Experiment Datum: Mon, 22 Jul 2013 13:15:23 -0700 Von: IAB Chair <mailto:iab-chair at ietf.org> <iab-chair at ietf.org> Antwort an: ietf at ietf.org An: 87all at ietf.org The OPUS codec, defined in RFC 6716, can scale from low bit-rate narrowba...

...? I've never seen it in other documents. Specifically, this part: "This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English." Unless it is required now by the IETF I would advise to remove it. You are placing restrictions which do not usually appear(?) and may otherwise conflict with IETF guidelines. It actually differs from the standard Intellectual Property and Full Copyright Statement clauses that proposed Standard Tracks documents carry at the bottom. F...

Dear all, A new IETF working group is being formed, chartered to maintain SSH protocol specifications. Please see the below announcement for more information. Kind regards, Job ----- Forwarded message from Deb Cooley <debcooley1 at gmail.com> ----- Date: Tue, 13 Aug 2024 18:24:56 -0400 From: Deb Cooley <de...

Hi folks, here's a press release (yes, sorry, sorry) regarding what's going on with Xiph at the current IETF meeting. Every time we're asked 'why haven't you standardized any of your codecs through the IETF?' we explain that we've been trying for coming up on ten years. This release is about the latest step. If we (along with the other companies supporting unencumbered media) demonst...

Hi folks, here's a press release (yes, sorry, sorry) regarding what's going on with Xiph at the current IETF meeting. Every time we're asked 'why haven't you standardized any of your codecs through the IETF?' we explain that we've been trying for coming up on ten years. This release is about the latest step. If we (along with the other companies supporting unencumbered media) demonst...

Hi, I have another sieve question, this time about setting variables. I join a lot of mailing lists at ietf.org. I thought it'd be handy to filter these all into a common folder and then into individual folders, without having to configure each mailing list independently. So wrote this (this is just a part, obviously): require ["envelope", "variables", "date", "f...

Dear all, We are excited to announce that the our CELLAR working group charter for the standardization of FFV1, Matroska, and FLAC has been made available for external review. What this means is that it is now under review and available for comment to the wider IETF community. Please send any comments you might have(including statement of support)to the IESG mailing list by November 9, 2015. The mailing list for review comments is here: iesg at ietf.org In the upcoming weeks, we will begin actively posting to the newly established CELLAR working group maili...

Begin forwarded message: > From: Barry Leiba <barryleiba at computer.org> > Date: 20. marraskuuta 2012 2.44.51 UTC+2.00 > To: imap5 at ietf.org, imapext at ietf.org, imap-protocol at u.washington.edu, imap-use at u.washington.edu > Subject: [imapext] News about Mark Crispin > Reply-To: imap5 at ietf.org > > Everyone here knows Mark Crispin -- or at least knows who he is: Mark is the author of the original IMAP specificatio...

...al use of independent (intra) frames. CELT now supports a larger dynamic range, suitable for encoding 24-bit audio (float version only). There is also a very early VBR implementation. Now, 0.6.0 is also the version that just got submitted as an "IPR-free codec" Internet draft: http://www.ietf.org/internet-drafts/draft-valin-celt-codec-00.txt For those who aren't aware of it, there is an ongoing discussion about creating an IETF working group for standardising unencumbered audio codecs that everyone can use. There will be a BoF at the next IETF meeting (26-31 July) in Stockholm to d...

Jean-Marc Valin wrote: >> Also, we need to know why there is a "license" chapter (chapter 9) >> and we need to remove it because ietf don't like it... > > IIRC, the reason for the license is to make the document compatible with > the Debian licensing guidelines or something like that. > I would like to know if we should keep this additional license chapter or not ..? Please advice, if you have any input.. if w...

...========== JABBER: accountone INCOMING: <stream:stream from="domain.com at gmail.com" id="C28AAAAAAAC2E0" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client"><stream:features><starttlsxmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls> <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>X-GOOGLE-TOKEN</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms></stream:features> JABBER: accountone OUTGO...

On 3/30/09, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote: > It seems to be related to debian, that doesn't like the fact that not > everyone is allowed to modify these documents. If it's that much > problem, I'd say just remove it. Guys, both the Vorbis RTP and the Ogg media types RFCs have this clause. It did not raise any problem. If there are problems

Hi All, I've been working on a diff to get SSHFP support for ed25519 in OpenSSH. SM has been working through the IETF process to obtain the SSHFP RR Type number. Despite getting "rough consensus", we still haven't heard anything from the IETF Security Directors for the draft. SM sent a mail asking why it is taking so long, and it appears that his mail was ignored. Please see: http://www.ietf.org/ma...

Hi everyone, Here's a follow-up on the two BoFs we've had about doing royalty-free codecs at the IETF. Well, the good new is that the proposal is now in IETF last call until January 20th (see below). No final decision has been made, so it's important to get as much support as possible for the Working Group proposal. You can see the ongoing discussion on the mailing list archive: http://www....

Hi everyone, Here's a follow-up on the two BoFs we've had about doing royalty-free codecs at the IETF. Well, the good new is that the proposal is now in IETF last call until January 20th (see below). No final decision has been made, so it's important to get as much support as possible for the Working Group proposal. You can see the ongoing discussion on the mailing list archive: http://www....

On 4/7/2015 10:48 PM, Andrew Sullivan wrote: > Hi, > > I have another sieve question, this time about setting variables. > > I join a lot of mailing lists at ietf.org. I thought it'd be handy to > filter these all into a common folder and then into individual > folders, without having to configure each mailing list independently. > > So wrote this (this is just a part, obviously): > > require ["envelope", "variables&quot...