Re: [Standards] LAST CALL: XEP-0266 (Codecs for Jingle Audio)
On Fri Jun 17 03:44:13 2011, dmex wrote: Am I emailing play school? One of these things is not like the others, one of these things does not belong. Possibly from one. A codec that has patent issues and not finalized is something that does not belong. End of story. Firstly, Opus does not have patent issues. It has IPR claims, and there's a world of difference, not least because patents are a reality, whereas IPR claims are just that - claims. To remove it based on the claims implies that the XSF believes them valid, whereas - I hope - the XSF takes no position on the validity of the claims. Imagine if this came to court, and some bright lawyer says Well, the XSF removed it from their list, so obviously they think the claims are valid. - we'd be effectively supporting the validity by removing it at this point. Secondly, the document makes it clear that Opus is not yet ready, but given it's intended as the successor to Speex, it'd be odd not to include it. It's certainly intended for exactly this kind of usage, and it's a piece of work that Jingle Audio implementers absolutely should be aware of. Do I really need to list reasons why this having this codec listed on this document is a bad idea? Some valid reasons would help. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] LAST CALL: XEP-0266 (Codecs for Jingle Audio)
Am 17.06.2011 04:44, schrieb dmex: Q: What is the most annoying behavior on email discussion lists? A: People who don't contribute to the discussion like the Executive Director? ;) You did of course read his not top-posted contribution to the discussion, right? Am I emailing play school? One of these things is not like the others, one of these things does not belong. I doubt being condescending will get you anywhere... A codec that has patent issues and not finalized is something that does not belong. End of story. Do I really need to list reasons why this having this codec listed on this document is a bad idea? That would be a good start since apparently at least one person on this list disagrees with your assessment. And just to have contributed something to the discussion: I personally don't care if Opus is in the XEP if it is in the current form (clearly stating the situation on IPR issues), but I think it's somewhat strange to include information on something that is still very much in flux. -- Florian Zeitz -Original Message- From: Peter Saint-Andre [mailto:stpe...@stpeter.im] Sent: Friday, 17 June 2011 9:21 AM To: XMPP Standards Cc: dmex Subject: Re: [Standards] LAST CALL: XEP-0266 (Codecs for Jingle Audio) First of all, Section of XEP-0266 is purely informational -- it lists selected codecs that might meet the criteria set out in Section 2. I'd agree that it would be premature to make Opus RECOMMENDED, but this spec doesn't do that, so I don't understand your objection. Peter
[Standards] XEP-198 when to start counting?
When I test stream management with a prosody server, this happens: !-- Out -- enable xmlns=urn:xmpp:sm:2 resume=true / !-- Out -- iq type=set id=2 session xmlns=urn:ietf:params:xml:ns:xmpp-session / /iq !-- In -- enabled id='a8110118-42ec-485c-b386-85b2d12a02a1' resume='true' xmlns='urn:xmpp:sm:2'/ !-- Out -- r xmlns=urn:xmpp:sm:2 / !-- In -- iq id='2' type='result' to='jt...@thiessen.im/919aece2-21f2-4fc4-9e02-ac522509_'/ r xmlns='urn:xmpp:sm:2'/ !-- Out -- a xmlns=urn:xmpp:sm:2 h=1 / The client sent an IQ stanza before it received confirmation for SM negotiation enabled /. When should I start counting? When I send enable / or when I receive enabled /? Also in the XEP document, section 11.3 Stream Features. It says that The XMPP Registrar includes 'urn:xmpp:sm:3' in its registry of stream features at http://xmpp.org/registrar/stream-features.html. But at that URL you can't find 'urn:xmpp:sm:3', only 'urn:xmpp:sm:2' is there. -- Jefry Lagrange
Re: [Standards] XEP-198 when to start counting?
On 17 June 2011 18:25, Jefry Lagrange jefry.re...@gmail.com wrote: When I test stream management with a prosody server, this happens: !-- Out -- enable xmlns=urn:xmpp:sm:2 resume=true / !-- Out -- iq type=set id=2 session xmlns=urn:ietf:params:xml:ns:xmpp-session / /iq !-- In -- enabled id='a8110118-42ec-485c-b386-85b2d12a02a1' resume='true' xmlns='urn:xmpp:sm:2'/ !-- Out -- r xmlns=urn:xmpp:sm:2 / !-- In -- iq id='2' type='result' to='jt...@thiessen.im/919aece2-21f2-4fc4-9e02-ac522509_'/ r xmlns='urn:xmpp:sm:2'/ !-- Out -- a xmlns=urn:xmpp:sm:2 h=1 / The client sent an IQ stanza before it received confirmation for SM negotiation enabled /. When should I start counting? When I send enable / or when I receive enabled /? When you send enable/, if you're going to send stanzas before you receive enabled/. The XEP says this: The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled, is incremented to one for the first stanza handled, and is incremented by one again with each subsequent stanza handled. ...which isn't too decisive, to say the least :) You should definitely start counting from when you send enable/, because it is from receiving that that the server starts counting on its end and because it has no idea at what time you, the client, receive the enabled/. Also in the XEP document, section 11.3 Stream Features. It says that The XMPP Registrar includes 'urn:xmpp:sm:3' in its registry of stream features at http://xmpp.org/registrar/stream-features.html. But at that URL you can't find 'urn:xmpp:sm:3', only 'urn:xmpp:sm:2' is there. Probably a communications failure between the XEP Editor and the XMPP Registrar :) Regards, Matthew
Re: [Standards] XEP-198 when to start counting?
On 6/17/11 11:37 AM, Matthew Wild wrote: On 17 June 2011 18:25, Jefry Lagrange jefry.re...@gmail.com wrote: When I test stream management with a prosody server, this happens: !-- Out -- enable xmlns=urn:xmpp:sm:2 resume=true / !-- Out -- iq type=set id=2 session xmlns=urn:ietf:params:xml:ns:xmpp-session / /iq !-- In -- enabled id='a8110118-42ec-485c-b386-85b2d12a02a1' resume='true' xmlns='urn:xmpp:sm:2'/ !-- Out -- r xmlns=urn:xmpp:sm:2 / !-- In -- iq id='2' type='result' to='jt...@thiessen.im/919aece2-21f2-4fc4-9e02-ac522509_'/ r xmlns='urn:xmpp:sm:2'/ !-- Out -- a xmlns=urn:xmpp:sm:2 h=1 / The client sent an IQ stanza before it received confirmation for SM negotiation enabled /. When should I start counting? When I send enable / or when I receive enabled /? When you send enable/, if you're going to send stanzas before you receive enabled/. The XEP says this: The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled, is incremented to one for the first stanza handled, and is incremented by one again with each subsequent stanza handled. ...which isn't too decisive, to say the least :) Seems clear to me. Feel free to propose revised text. You should definitely start counting from when you send enable/, because it is from receiving that that the server starts counting on its end and because it has no idea at what time you, the client, receive the enabled/. Also in the XEP document, section 11.3 Stream Features. It says that The XMPP Registrar includes 'urn:xmpp:sm:3' in its registry of stream features at http://xmpp.org/registrar/stream-features.html. But at that URL you can't find 'urn:xmpp:sm:3', only 'urn:xmpp:sm:2' is there. Probably a communications failure between the XEP Editor and the XMPP Registrar :) Indeed, those two roles within the XSF notoriously have trouble keeping things straight. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-198 when to start counting?
On 17 June 2011 18:40, Peter Saint-Andre stpe...@stpeter.im wrote: On 6/17/11 11:37 AM, Matthew Wild wrote: On 17 June 2011 18:25, Jefry Lagrange jefry.re...@gmail.com wrote: When I test stream management with a prosody server, this happens: !-- Out -- enable xmlns=urn:xmpp:sm:2 resume=true / !-- Out -- iq type=set id=2 session xmlns=urn:ietf:params:xml:ns:xmpp-session / /iq !-- In -- enabled id='a8110118-42ec-485c-b386-85b2d12a02a1' resume='true' xmlns='urn:xmpp:sm:2'/ !-- Out -- r xmlns=urn:xmpp:sm:2 / !-- In -- iq id='2' type='result' to='jt...@thiessen.im/919aece2-21f2-4fc4-9e02-ac522509_'/ r xmlns='urn:xmpp:sm:2'/ !-- Out -- a xmlns=urn:xmpp:sm:2 h=1 / The client sent an IQ stanza before it received confirmation for SM negotiation enabled /. When should I start counting? When I send enable / or when I receive enabled /? When you send enable/, if you're going to send stanzas before you receive enabled/. The XEP says this: The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled, is incremented to one for the first stanza handled, and is incremented by one again with each subsequent stanza handled. ...which isn't too decisive, to say the least :) Seems clear to me. Feel free to propose revised text. I was about to, but then noticed that actually just below the whole thing is already clarified in a note. So perhaps after requested to be enabled simply insert (see note below) - the box clarifies both the client and server side of the proceedings. Jefry - does the note in the XEP (the box just before example 6) leave you with any question about what the correct behaviour is? It seems to answer your question perfectly. Regards, Matthew
Re: [Standards] XEP-198 when to start counting?
On 6/17/11 11:52 AM, Matthew Wild wrote: On 17 June 2011 18:40, Peter Saint-Andre stpe...@stpeter.im wrote: On 6/17/11 11:37 AM, Matthew Wild wrote: On 17 June 2011 18:25, Jefry Lagrange jefry.re...@gmail.com wrote: When I test stream management with a prosody server, this happens: !-- Out -- enable xmlns=urn:xmpp:sm:2 resume=true / !-- Out -- iq type=set id=2 session xmlns=urn:ietf:params:xml:ns:xmpp-session / /iq !-- In -- enabled id='a8110118-42ec-485c-b386-85b2d12a02a1' resume='true' xmlns='urn:xmpp:sm:2'/ !-- Out -- r xmlns=urn:xmpp:sm:2 / !-- In -- iq id='2' type='result' to='jt...@thiessen.im/919aece2-21f2-4fc4-9e02-ac522509_'/ r xmlns='urn:xmpp:sm:2'/ !-- Out -- a xmlns=urn:xmpp:sm:2 h=1 / The client sent an IQ stanza before it received confirmation for SM negotiation enabled /. When should I start counting? When I send enable / or when I receive enabled /? When you send enable/, if you're going to send stanzas before you receive enabled/. The XEP says this: The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled, is incremented to one for the first stanza handled, and is incremented by one again with each subsequent stanza handled. ...which isn't too decisive, to say the least :) Seems clear to me. Feel free to propose revised text. I was about to, but then noticed that actually just below the whole thing is already clarified in a note. So perhaps after requested to be enabled simply insert (see note below) - the box clarifies both the client and server side of the proceedings. Jefry - does the note in the XEP (the box just before example 6) leave you with any question about what the correct behaviour is? It seems to answer your question perfectly. That's why we added it. :) Now, why v1.3rc2 is published on the website already before it has been approved by the XMPP Council is another question... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] LAST CALL: XEP-0266 (Codecs for Jingle Audio)
On 6/17/11 3:24 AM, Florian Zeitz wrote: I personally don't care if Opus is in the XEP if it is in the current form (clearly stating the situation on IPR issues), but I think it's somewhat strange to include information on something that is still very much in flux. Well, it's mostly based on CELT and SILK, which are quite stable. As Dave Cridland noted, it is also intended to be the successor to Speex, and in fact to both CELT and SILK. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Proposed XMPP Extension: In-Band Real Time Text
The XMPP Extensions Editor has received a proposal for a new XEP. Title: In-Band Real Time Text Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. URL: http://www.xmpp.org/extensions/inbox/realtimetext.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
Re: [Standards] Proposed XMPP Extension: In-Band Real Time Text
This is version 0.0.2, incorporating earlier feedback. On 6/17/11 8:10 PM, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: In-Band Real Time Text Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. URL: http://www.xmpp.org/extensions/inbox/realtimetext.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: In-Band Real Time Text
Hello, Thank you Peter -- we spent a lot of time rewriting the specification. The core part of the spec (section 4) is now half its original size -- All words MUST is confined only to Section 4. I'd like to bring attention to www.realjabber.org which has become a go-to site for XMPP-based real time text technology. It contains an important animation that shows what real time text looks like, useful for explaining to people, what real time text is for. Sincerely, Mark Rejhon On Fri, Jun 17, 2011 at 10:41 PM, Peter Saint-Andre stpe...@stpeter.imwrote: This is version 0.0.2, incorporating earlier feedback. On 6/17/11 8:10 PM, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: In-Band Real Time Text Abstract: This is a specification for real-time text transmitted in-band over an XMPP session. URL: http://www.xmpp.org/extensions/inbox/realtimetext.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
