On Mar 12, 2009, at 4:29 PM, Peter Saint-Andre wrote:
The phrase "when the server gives stream features for resumption"
could
mean two things:
1. Whenever a server that supports stream resumption sends stream
features.
OR
2. When a server sends stream features to an initiating entity th
Jack Moffitt wrote:
So RFC 2831 says:
digest-uri-value = serv-type "/" host [ "/" serv-name ]
and RFC 3920 does not seem to specify anything else.
Implementations seem to expect xmpp/DOMAIN whre DOMAIN is the domain
part of the JID.
One reading of 2831 might lead one to implement something
On 3/12/09 4:45 PM, Jack Moffitt wrote:
> So RFC 2831 says:
>
> digest-uri-value = serv-type "/" host [ "/" serv-name ]
DIGEST-MD5 is being deprecated by the IETF:
http://tools.ietf.org/html/draft-ietf-sasl-digest-to-historic
> and RFC 3920 does not seem to specify anything else.
>
> Implemen
On Mar 12, 2009, at 3:45 PM, Jack Moffitt wrote:
So RFC 2831 says:
digest-uri-value = serv-type "/" host [ "/" serv-name ]
and RFC 3920 does not seem to specify anything else.
Implementations seem to expect xmpp/DOMAIN whre DOMAIN is the domain
part of the JID.
One reading of 2831 might le
So RFC 2831 says:
digest-uri-value = serv-type "/" host [ "/" serv-name ]
and RFC 3920 does not seem to specify anything else.
Implementations seem to expect xmpp/DOMAIN whre DOMAIN is the domain
part of the JID.
One reading of 2831 might lead one to implement something like:
xmpp/talk.google.
On 3/12/09 8:03 AM, Peter Saint-Andre wrote:
>
> On 3/7/09 10:45 AM, Joe Hildebrand wrote:
>> On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote:
>>
>>> On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote:
>>>
- When the server gives stream features for resumption, it MAY
include a hostname
I have received requests to add the following service discovery
identities to the registry: [1]
gateway/mrim for "mail.ru IM" a.k.a. MrIM [2]
gateway/myspaceim for MySpace IM [3]
gateway/facebook for Facebook IM [4]
If there are no objections I shall add these identities to the registry.
/psa
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: OutOfBand Stream Data
Abstract: This specification defines how to send parts of an XML stream over a
direct connection between peers. This allows to send large stanzas or binary
data without blocking the XML stream for oth
Fabio Forno ha scritto:
On Thu, Mar 12, 2009 at 5:16 PM, Peter Saint-Andre wrote:
Developers have been poking me about roster versioning:
http://xmpp.org/extensions/xep-0237.html
In fact developers are already implementing it. :)
So we need to make a final decision:
1. Do we limit this
On Thu, Mar 12, 2009 at 5:16 PM, Peter Saint-Andre wrote:
> Developers have been poking me about roster versioning:
>
> http://xmpp.org/extensions/xep-0237.html
>
> In fact developers are already implementing it. :)
>
> So we need to make a final decision:
>
> 1. Do we limit this to rosters?
>
>
On 3/12/09 7:59 AM, Kurt Zeilenga wrote:
> An additional comment The document should be more explicit that it is
> improper for the client to request the IP address the server
> associations with it from any other server than that it is directly
> attached to, and that when faced with an inappropr
On 3/12/09 12:06 PM, Matthew Wild wrote:
> On Thu, Mar 12, 2009 at 5:53 PM, Peter Saint-Andre wrote:
>> On 3/12/09 11:53 AM, Matthew Wild wrote:
>>> On Thu, Mar 12, 2009 at 5:36 PM, Pedro Melo wrote:
On a side note: For the disco situation, the hash-based caps work already,
and we coul
On Thu, Mar 12, 2009 at 5:53 PM, Peter Saint-Andre wrote:
> On 3/12/09 11:53 AM, Matthew Wild wrote:
>> On Thu, Mar 12, 2009 at 5:36 PM, Pedro Melo wrote:
>>> On a side note: For the disco situation, the hash-based caps work already,
>>> and we could ask server vendors to send a server presence
On 3/12/09 11:53 AM, Matthew Wild wrote:
> On Thu, Mar 12, 2009 at 5:36 PM, Pedro Melo wrote:
>> On a side note: For the disco situation, the hash-based caps work already,
>> and we could ask server vendors to send a server presence on connect with
>> their own caps. Caps to cache server disco#in
On Thu, Mar 12, 2009 at 5:36 PM, Pedro Melo wrote:
>
> On a side note: For the disco situation, the hash-based caps work already,
> and we could ask server vendors to send a server presence on connect with
> their own caps. Caps to cache server disco#info might just work.
>
http://xmpp.org/exten
On 3/12/09 11:36 AM, Pedro Melo wrote:
>
> On Mar 12, 2009, at 4:16 PM, Peter Saint-Andre wrote:
>
>> Developers have been poking me about roster versioning:
>>
>> http://xmpp.org/extensions/xep-0237.html
>>
>> In fact developers are already implementing it. :)
>>
>> So we need to make a final de
On Mar 12, 2009, at 4:16 PM, Peter Saint-Andre wrote:
Developers have been poking me about roster versioning:
http://xmpp.org/extensions/xep-0237.html
In fact developers are already implementing it. :)
So we need to make a final decision:
1. Do we limit this to rosters?
Implica
Developers have been poking me about roster versioning:
http://xmpp.org/extensions/xep-0237.html
In fact developers are already implementing it. :)
So we need to make a final decision:
1. Do we limit this to rosters?
Implications: (a) it is included in rfc3921bis (b) it can't be
On Mar 10, 2009, at 1:47 PM, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Server IP Check
Abstract:
URL: http://www.xmpp.org/extensions/inbox/sic.html
The XMPP Council will decide at its next meeting whether to accept
this proposa
> Some suggested changes. I suspect a couple will result in some discussion
> on this list. :-)
+1 for me.
cheers,
Remko
Sorry, just catching up on the thread. An interesting discussion. :)
On 3/7/09 10:45 AM, Joe Hildebrand wrote:
> On Mar 7, 2009, at 2:07 AM, Dave Cridland wrote:
>
>> On Sat Mar 7 00:49:30 2009, Joe Hildebrand wrote:
>>> I actually think that moving stream management after the bind is a
>>> goo
An additional comment The document should be more explicit that it is
improper for the client to request the IP address the server
associations with it from any other server than that it is directly
attached to, and that when faced with an inappropriate request, the
server MUST rejected it
On Mar 10, 2009, at 1:47 PM, XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Server IP Check
Abstract:
URL: http://www.xmpp.org/extensions/inbox/sic.html
The XMPP Council will decide at its next meeting whether to accept
this proposa
23 matches
Mail list logo
