Re: [Standards] XEP 0131
Johansson Olle E wrote: 8 aug 2008 kl. 15.41 skrev Peter Saint-Andre: Johansson Olle E wrote: XEP 0131 (Stanza headers and Internet Metadata) defines a lot of headers that are referenced to RFC 3261 - SIP. Is there any underlying document that explains the selection and the usage? As an example, the "Call-ID" header is a bit odd, since it's only valid in the SIP call path and in my opinion should not be re-used in the XMPP path as a header, an ID for that call leg. There was no selection -- basically we said "you can re-use any of the headers you might want or need from HTTP, SMTP, NNTP, SIP, etc.". Ok, maybe we need to clarify a few of them in the interoperability docs. Oh sure, clarification is always good. :) Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
Pavel Simerda wrote: On Fri, 08 Aug 2008 08:36:12 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: Pavel Simerda wrote: URL: http://www.xmpp.org/extensions/xep-0231.html That's it :). Super. So now I think we need to issue a second Last Call on XEP-0231, XEP-0221, and XEP-0158, because they have changed quite a bit since the previous Last Call. And I think now XEP-0231 and XEP-0221 will be more palatable to Council member Ralph Meijer, who did not like the inclusion of binary data in x:data forms. /psa Btw, I had to lookup 'palatable in a dictionary :). If he'll be more content with it, it's only good, it's a pity I didn't see any of his comments or concerns. In one of the recent XMPP Council meetings he expressed a vague discomfort about XEP-0221 because he didn't think that it was right to include the binary data directly in an x:data form, so I think he may prefer our "bits of binary" approach. /psa smime.p7s Description: S/MIME Cryptographic Signature
[Standards] LAST CALL: XEP-0158 (CAPTCHA Forms)
This message constitutes notice of a Last Call for comments on XEP-0158 (CAPTCHA Forms). Abstract: This document specifies an XMPP protocol extension that entities may use to discover whether the sender of an XML stanza is a human user or a robot. URL: http://www.xmpp.org/extensions/xep-0158.html This Last Call begins today and shall end at the close of business on 2008-08-22. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
[Standards] LAST CALL: XEP-0221 (Data Forms Media Element)
This message constitutes notice of a Last Call for comments on XEP-0221 (Data Forms Media Element). Abstract: This specification defines an XMPP protocol extension for including media data in XEP-0004 data forms. URL: http://www.xmpp.org/extensions/xep-0221.html This Last Call begins today and shall end at the close of business on 2008-08-22. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
[Standards] LAST CALL: XEP-0231 (Bits of Binary)
This message constitutes notice of a Last Call for comments on XEP-0231 (Bits of Binary). Abstract: This specification defines an XMPP protocol extension for including or referring to small bits of binary data in an XML stanza. URL: http://www.xmpp.org/extensions/xep-0231.html This Last Call begins today and shall end at the close of business on 2008-08-22. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
On Fri, 08 Aug 2008 08:36:12 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Pavel Simerda wrote: > > >> URL: http://www.xmpp.org/extensions/xep-0231.html > > > > That's it :). > > Super. So now I think we need to issue a second Last Call on > XEP-0231, XEP-0221, and XEP-0158, because they have changed quite a > bit since the previous Last Call. And I think now XEP-0231 and > XEP-0221 will be more palatable to Council member Ralph Meijer, who > did not like the inclusion of binary data in x:data forms. > > /psa > Btw, I had to lookup 'palatable in a dictionary :). If he'll be more content with it, it's only good, it's a pity I didn't see any of his comments or concerns. Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
Pavel Simerda wrote: URL: http://www.xmpp.org/extensions/xep-0231.html That's it :). Super. So now I think we need to issue a second Last Call on XEP-0231, XEP-0221, and XEP-0158, because they have changed quite a bit since the previous Last Call. And I think now XEP-0231 and XEP-0221 will be more palatable to Council member Ralph Meijer, who did not like the inclusion of binary data in x:data forms. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP 0131
8 aug 2008 kl. 15.41 skrev Peter Saint-Andre: Johansson Olle E wrote: XEP 0131 (Stanza headers and Internet Metadata) defines a lot of headers that are referenced to RFC 3261 - SIP. Is there any underlying document that explains the selection and the usage? As an example, the "Call-ID" header is a bit odd, since it's only valid in the SIP call path and in my opinion should not be re-used in the XMPP path as a header, an ID for that call leg. There was no selection -- basically we said "you can re-use any of the headers you might want or need from HTTP, SMTP, NNTP, SIP, etc.". Ok, maybe we need to clarify a few of them in the interoperability docs. /O smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] UPDATED: XEP-0231 (Bits of Binary)
On Thu, 07 Aug 2008 20:39:19 -0500 XMPP Extensions Editor <[EMAIL PROTECTED]> wrote: > Version 0.8 of XEP-0231 (Bits of Binary) has been released. > > Abstract: This specification defines an XMPP protocol extension for > including or referring to small bits of binary data in an XML stanza. > > Changelog: Added section on determining support. (psa/ps) > > Diff: http://is.gd/1j1T > > URL: http://www.xmpp.org/extensions/xep-0231.html > That's it :). -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP 0131
Johansson Olle E wrote: XEP 0131 (Stanza headers and Internet Metadata) defines a lot of headers that are referenced to RFC 3261 - SIP. Is there any underlying document that explains the selection and the usage? As an example, the "Call-ID" header is a bit odd, since it's only valid in the SIP call path and in my opinion should not be re-used in the XMPP path as a header, an ID for that call leg. There was no selection -- basically we said "you can re-use any of the headers you might want or need from HTTP, SMTP, NNTP, SIP, etc.". /psa smime.p7s Description: S/MIME Cryptographic Signature
[Standards] XEP 0131
XEP 0131 (Stanza headers and Internet Metadata) defines a lot of headers that are referenced to RFC 3261 - SIP. Is there any underlying document that explains the selection and the usage? As an example, the "Call-ID" header is a bit odd, since it's only valid in the SIP call path and in my opinion should not be re-used in the XMPP path as a header, an ID for that call leg. /O smime.p7s Description: S/MIME cryptographic signature
