Re: [Standards] Correction to 3290bis4
Peter Saint-Andre wrote: Toly Menn wrote: Also, section 7.3.4 indicates that the receiving end of the connection SHOULD allow at least 2 and no more then 5 retries from the abort. Does this make sense for s2s connections? EXTERNAL mechanism? That rule (which IIRC we borrowed from RFC 4422) may not make sense for all SASL mechanisms or for s2s connections. Agreed. However, for c2s connections it may make sense for SASL EXTERNAL because end users can have multiple certificates (I know I do). As a side note: how do you select a particular certificate using SASL EXTERNAL? Are you using different authorization identity in a hope that the server end will match it against the correct client certificate.
Re: [Standards] Correction to 3290bis4
On Friday 02 November 2007 1:44 am, Alexey Melnikov wrote: Peter Saint-Andre wrote: Toly Menn wrote: Also, section 7.3.4 indicates that the receiving end of the connection SHOULD allow at least 2 and no more then 5 retries from the abort. Does this make sense for s2s connections? EXTERNAL mechanism? That rule (which IIRC we borrowed from RFC 4422) may not make sense for all SASL mechanisms or for s2s connections. Agreed. However, for c2s connections it may make sense for SASL EXTERNAL because end users can have multiple certificates (I know I do). As a side note: how do you select a particular certificate using SASL EXTERNAL? Are you using different authorization identity in a hope that the server end will match it against the correct client certificate. You don't select a particular certificate, you select a particular identity from that certificate. Suppose you could three JIDs in a cert, and you present that cert during the TLS negotiation. The authzid used during SASL EXTERNAL allows you to pick which identity to act as. Thus, retrying with EXTERNAL is useful for people with certificates that contain many identities. However, it is not useful for people who have multiple certificates. -Justin
Re: [Standards] rfc3921bis: ask='subscribed'
Dnia 01-11-2007, Cz o godzinie 17:10 -0600, Peter Saint-Andre pisze: ## COMMENT: Footnote [1] here is the flip side -- how the user's server shall handle an inbound subscribe from the contact if the user pre-approved the contact's presence subscription. ## Autoreply with subscribed, and send normal roster-push to the user. Thoughts? Good idea. I'm willing to implement it. :-) -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] [Fwd: Protocol Action: 'Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols' to Proposed Standard]
Finally !!! I can't believe! We are now more confident to go to ICE. Best Regards, Thiago - Original Message - From: Peter Saint-Andre [EMAIL PROTECTED] To: standards@xmpp.org Sent: Tuesday, October 30, 2007 7:39:41 PM (GMT-0300) Auto-Detected Subject: [Standards] [Fwd: Protocol Action: 'Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols' to Proposed Standard] FYI re: Jingle. Original Message From: The IESG [EMAIL PROTECTED] To: IETF-Announce [EMAIL PROTECTED] Date: Tue, 30 Oct 2007 16:50:53 -0400 Cc: mmusic chair [EMAIL PROTECTED], Internet Architecture Board [EMAIL PROTECTED], mmusic mailing list [EMAIL PROTECTED], RFC Editor [EMAIL PROTECTED] Subject: Protocol Action: 'Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols' to Proposed Standard The IESG has approved the following document: - 'Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols ' draft-ietf-mmusic-ice-19.txt as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-19.txt Technical Summary This document defines a protocol for Network Address Translator (NAT) traversal for multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). Working Group Summary The MMUSIC Working Group has consensus to publish this document as a Proposed Standard. Document Quality Previous versions of this protocol have been implemented. A number of implementers have indicated plans to support this protocol once published. Personnel The Document Shepherd is Jean-Francois Mule, and the Responsible Area Director is Cullen Jennings. Note to RFC Editor Please change the header so that it obsoletes both 4091 and 4092. OLD Obsoletes: RFC 4091 NEW Obsoletes: RFC 4091, 4092 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
[Standards] [Fwd: I-D Action:draft-klensin-idnabis-protocol-00.txt]
Given that XMPP depends on IDNA, this may be of interest... /psa Original Message To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Date: Fri, 02 Nov 2007 15:20:02 -0400 Subject: I-D Action:draft-klensin-idnabis-protocol-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalizing Domain Names in Applications (IDNA): Protocol Author(s) : J. Klensin Filename: draft-klensin-idnabis-protocol-00.txt Pages : 17 Date: 2007-11-02 This document supplies the protocol definition for a revised and updated specification for internationalized domain names. The rationale for these changes and relationship to the older specification and some new terminology is provided in other documents. This document specifies a standard method using characters outside the ASCII repertoire in domain names. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large subset of the Unicode repertoire, but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-klensin-idnabis-protocol-00.txt snip/ Message/External-body; name="draft-klensin-idnabis-protocol-00.txt": Unrecognized ___ I-D-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/i-d-announce smime.p7s Description: S/MIME Cryptographic Signature
