Re: [Standards] NEW: XEP-0225 (Component Connections)

[Joe Hildebrand]

On Aug 9, 2007, at 10:01 PM, Justin Karneges wrote:
There's an even bigger one: server connections can only send  
stanzas in one
direction.  Although that's more of a protocol thing than a schema  
thing, if

you want to get picky. :)


This is a good enough reason for me, which is why I like jabber:client.

--
Joe Hildebrand

Re: [Standards] MUC rooms on roster.

[Joe Hildebrand]

On Aug 3, 2007, at 3:10 AM, Robin Redeker wrote:

Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ?
That would still be useful to store non-autmatically-joined MUCs I  
guess?

Also that XEP offers also a way to auto-join MUCs.


The more we talked about this around the office, the more we thought  
we only needed two things to make this work for our use cases.


1) A new MUC role which effectively the opposite of visitor.  Of  
course, on the bar napkin, this got written as "rotisiv". :)  A  
rotisiv can potentially speak (broadcasting to all of the members of  
the room), but can't see any of the messages that are broadcast to  
the room.  As well, rotisivs get presence from all of the  
participants and moderators of the room, but nobody receives the  
rotisiv's presence from the room.  Obviously, an implementation might  
want ACLs to specify who can be a rotisiv for a given room.


2) An addition to xep-48 that gives a little more meta-data.


  

  



  

  


Just as for normal MUC, the client sends a separate presence stanza  
to each group they are a participant in or moderator of, whenever the  
user changes presence; this allows a client can use its existing MUC  
and bookmarks implementation to do whatever UI they want, manage  
which groups they appear online to, and the like.  In this case,  
pushing a small amount of complexity down to the client (which the  
client probably already has anyway) leads to a vast simplification in  
the server implementation.  It's very apparent which presence is  
group-related for clients that want to do special UIs, and existing  
clients that haven't implemented the new feature get to participate  
in groups.


--
Joe Hildebrand

Re: [Standards] NEW: XEP-0225 (Component Connections)

[Justin Karneges]

On Thursday 09 August 2007 8:03 pm, Peter Saint-Andre wrote:
> Hi Matthias! :)
>
> Matthias Wimmer wrote:
> > Hi Peter!
> >
> > Peter Saint-Andre schrieb:
> >> I don't have a strong preference really. A component feels a bit more
> >> like a client because it is a local connection, plus c2s connections are
> >> simpler than s2s connections. Let's pick one and be done with it. :)
> >
> > The reason why I for the most part suggest using jabber:server instead
> > of jabber:client is, that in the jabber:client namespace the from
> > attribute on stanza is optional, while on jabber:server it is not. I
> > think this is one of the biggest differences between these two
> > namespaces.
>
> In fact I think it's the only difference. ;-)

There's an even bigger one: server connections can only send stanzas in one 
direction.  Although that's more of a protocol thing than a schema thing, if 
you want to get picky. :)

> As I said, I think there are reasons to go with either jabber:client or
> jabber:server. It may more more a matter of picking one than choosing
> based on some reasoning.

I always figured components were more like clients than servers.  Clients and 
components make single outbound connections, and construct and parse stanzas 
for server routing.  In contrast, servers do very little stanza manipulation 
(and, depending on how your server is designed, even the roster stuff might 
be in a component).  It is stanza manipulation that really kicks your ass 
when it comes to the different namespaces, and so sharing the same one as 
clients would be useful I think.

-Justin

Re: [Standards] NEW: XEP-0225 (Component Connections)

[Peter Saint-Andre]

Hi Matthias! :)

Matthias Wimmer wrote:
> Hi Peter!
> 
> Peter Saint-Andre schrieb:
>> I don't have a strong preference really. A component feels a bit more
>> like a client because it is a local connection, plus c2s connections are
>> simpler than s2s connections. Let's pick one and be done with it. :)
> 
> 
> The reason why I for the most part suggest using jabber:server instead
> of jabber:client is, that in the jabber:client namespace the from
> attribute on stanza is optional, while on jabber:server it is not. I
> think this is one of the biggest differences between these two
> namespaces. 

In fact I think it's the only difference. ;-)

> So the component connection which also forces this stanza
> attribute to be present matches better the jabber:server namespace.

True.

> Minor reasons:
> - I'd say that component connections are more like a s2s connection, as
> you do not manage sessions from them in the server. 

Good point. But I suppose that a session is tied to resource binding and
sending initial presence (we're getting rid of session establishment in
rfc3921bis for this reason -- a session is essentially a presence
session), so I don't know if this reason is relevant.

> - Both with s2s and components you typically route one or more domains
> completely to the same desination. With c2s you only route single users
> out of a domain.

Right.

As I said, I think there are reasons to go with either jabber:client or
jabber:server. It may more more a matter of picking one than choosing
based on some reasoning.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

[Peter Saint-Andre]

Olivier Goffart wrote:
> Le jeudi 9 août 2007, Peter Saint-Andre a écrit :
>> Olivier Goffart wrote:
>>> Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
 Version 0.1 of XEP-0224 (Attention) has been released.

 Abstract: This document defines an XMPP protocol extension for getting
 the attention of another user.
> 
 URL: http://www.xmpp.org/extensions/xep-0224.html
>>> One year ago, i also wrote a JEP about that (but never published it)
>>>
>>> The concept is quite the same.  (but i also defined a lower important
>>> message level)
>>>
>>> I did not publish it because I was thinking it could be included in the
>>> SHIM (XEP-0131)
>> You mean like this?
>>
>> http://www.xmpp.org/extensions/xep-0131.html#headers-urgency
> 
> Exactly.
> 
> If we agree that urgent message demand a particular attention, we have two 
> different specification for the same thing.
> 
> The only difference is that you may demand attention for the previous message 
> you sent.  The message which demand the attention is not urgent itself, only 
> the whole discussion is.
> Bu i think it probably doesn't matter.
> 
> What I suggest is to modify the XEP-0224 into a kind of "Best Practices" 
> or "Buisness rules" regarding important messages.

I think the idea behind "attention" is different. The reference to
XEP-0132 in the introduction to XEP-0224 is not just a joke. The
protocol is not intended as a way to flag a message as more important,
but literally to poke or prod the contact, as in "hey, pay attention".
Personally I don't think I would ever use the feature, but it's one of
those things that lots of end users think is cool, so who am I to deny
them their fun?

/psa





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0225 (Component Connections)

[Matthias Wimmer]

Hi Peter!

Peter Saint-Andre schrieb:

I don't have a strong preference really. A component feels a bit more
like a client because it is a local connection, plus c2s connections are
simpler than s2s connections. Let's pick one and be done with it. :)



The reason why I for the most part suggest using jabber:server instead 
of jabber:client is, that in the jabber:client namespace the from 
attribute on stanza is optional, while on jabber:server it is not. I 
think this is one of the biggest differences between these two 
namespaces. So the component connection which also forces this stanza 
attribute to be present matches better the jabber:server namespace.


Minor reasons:
- I'd say that component connections are more like a s2s connection, as 
you do not manage sessions from them in the server. pre-2.0 versions of 
jabberd2 even did not have a dedicated s2s component but did s2s 
directly in the router (where also components connect to).
- Both with s2s and components you typically route one or more domains 
completely to the same desination. With c2s you only route single users 
out of a domain.



Matthias

Re: [Standards] NEW: XEP-0224 (Attention)

[Olivier Goffart]

Le jeudi 9 août 2007, Peter Saint-Andre a écrit :
> Olivier Goffart wrote:
> > Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
> >> Version 0.1 of XEP-0224 (Attention) has been released.
> >>
> >> Abstract: This document defines an XMPP protocol extension for getting
> >> the attention of another user.

> >> URL: http://www.xmpp.org/extensions/xep-0224.html
> >
> > One year ago, i also wrote a JEP about that (but never published it)
> >
> > The concept is quite the same.  (but i also defined a lower important
> > message level)
> >
> > I did not publish it because I was thinking it could be included in the
> > SHIM (XEP-0131)
>
> You mean like this?
>
> http://www.xmpp.org/extensions/xep-0131.html#headers-urgency

Exactly.

If we agree that urgent message demand a particular attention, we have two 
different specification for the same thing.

The only difference is that you may demand attention for the previous message 
you sent.  The message which demand the attention is not urgent itself, only 
the whole discussion is.
Bu i think it probably doesn't matter.

What I suggest is to modify the XEP-0224 into a kind of "Best Practices" 
or "Buisness rules" regarding important messages.

-- 
Olivier

(PS: I've uploaded my old XEP to a web server so it's easier to read it:
http://bepointbe.be/files/notification_level.html )


signature.asc
Description: This is a digitally signed message part.

Re: [Standards] Jingle: UDP relays

[Evgeniy Khramtsov]

2007/8/10, Thiago Camargo <[EMAIL PROTECTED]>:
>
> UDP Relays are just simple UDP routers.
> So you can bind Ports and IPs to the clients from your XMPP servers.
> Clients don't need to negotiate directly with Relay Servers(TURN for
> instance).
> XMPP Servers can negotiate and allocate the tunnel to be used by the
> client.
>
> Check these drafts:
>
> http://www.gliffy.com/publish/1178640/
> http://www.gliffy.com/publish/1130091/
>
> Regards,
> Thiago
>

Hmm. And what about TCP-TCP and TCP-UDP relays?

Re: [Standards] NEW: XEP-0224 (Attention)

[Peter Saint-Andre]

Olivier Goffart wrote:
> Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
>> Version 0.1 of XEP-0224 (Attention) has been released.
>>
>> Abstract: This document defines an XMPP protocol extension for getting the
>> attention of another user.
>>
>> Changelog: Initial published version. (psa)
>>
>> Diff: N/A
>>
>> URL: http://www.xmpp.org/extensions/xep-0224.html
> 
> One year ago, i also wrote a JEP about that (but never published it)
> 
> The concept is quite the same.  (but i also defined a lower important message 
> level)
> 
> I did not publish it because I was thinking it could be included in the SHIM 
> (XEP-0131)

You mean like this?

http://www.xmpp.org/extensions/xep-0131.html#headers-urgency

/psa




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

[Olivier Goffart]

Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
> Version 0.1 of XEP-0224 (Attention) has been released.
>
> Abstract: This document defines an XMPP protocol extension for getting the
> attention of another user.
>
> Changelog: Initial published version. (psa)
>
> Diff: N/A
>
> URL: http://www.xmpp.org/extensions/xep-0224.html

One year ago, i also wrote a JEP about that (but never published it)

The concept is quite the same.  (but i also defined a lower important message 
level)

I did not publish it because I was thinking it could be included in the SHIM 
(XEP-0131)

Anyway, I've attached it.   
I think the lower important level is related and should be include to this 
XEP.

-- 
Olivier
Title: JEP-: notification levels



JEP-: notification levels
This JEP provides documentation for the notification level.

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at  and announced on the <[EMAIL PROTECTED]> mailing list.

JEP Information

Status: ProtoJEP
Type: Standards Track
Number: 
Version: 0.0.1
Last Updated: 2006-06-11
JIG: Standards JIG
Approving Body: Jabber CouncilDependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: notification levels
Author Information

Olivier Goffart

Email:
[EMAIL PROTECTED]
JID: 
[EMAIL PROTECTED]

Legal Notice
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy . This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License ().
Discussion Venue
The preferred venue for discussion of this document is the Standards-JIG discussion list: .
Relation to XMPP
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
Conformance Terms
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1.  Introduction

2.  Notification level

3.  Use Cases


3.1.  Lower message

3.2.  Urgent message


4.  Discovery

5.  Business Rules

6.  Implementation Notes

7.  Security Considerations

8.  IANA Considerations

9.  DTD

Notes
Revision History


1.
   Introduction

  This JEP let change the notification level of a message.  A different notification may be executed on the user's client depending the level.
  It allow to send message without disturbing a busy person, or at the opposite notify a busy person that the message is really urgent.
  It also describe how to do the equivalent of a wizz or a nudge in others messaging systems
2.
   Notification level

  We define the several notification level
  Table 1: Different notification level

	  
		  Level
		  Meaning
	  
	  
		  normal
		  This is the default level of all message without additional notification indication
	  
	  
		  lower
		  This mark a message which is not important and doesn't require immediate reply.
	  

	  
		  urgent
		  This is a message that require an immediate reply or action in return.
	  
  
3.
   Use Cases

  
3.1 Lower message

	  Romeo know that Juliet is busy, and don't want to distrub her, but would like to let her a message she could read when she is has time.
Example 1. Send a lower priority message


  I love you, Juliet
  
   

  
  
3.2 Urgent message

	  Juliet know that Romeo is busy, and is probably not paying attention to his massages, but has a very urgent message to 
		  communicate.
	  Example 2. Send a urgent message


  The reservation deadline for my father's ball ends in five minutes. Do you want to go there with me ?
  
   


  
4.
   Discovery

	It may be usefull to know if the client support that feature in order to let know the user that setting notification level will not have any effect
	Example 3.

Re: [Standards] NEW: XEP-0224 (Attention)

[Peter Saint-Andre]

Sergei Golovan wrote:
> On 8/10/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> Sergei Golovan wrote:
>>> This message looks like  but  is better because the
>>> recipient may receive result in case of accepted attention or error in
>>> case of ignored one. The ability of getting a response even makes
>>> disco#info queries unnecessary.
>> Yes this seems like an acceptable use of IQ to me, though I don't know
>> if you really need a response to an attention request.
> 
> Yes, I'd like to know if my attention request wasn't ignored by a
> recipient's client.

Fair enough, I have no objections to an IQ approach.

>>> I'd not call a responding on disco#info and disco#items query per
>>> recipient an overkill.
>> In this case it seems like overkill to me -- the client needs to keep
> 
> You're right that in case of attention support it's an overkill. So,
> I'd remove several MUSTs from the XEP. Namely, I don't feel that
> disco#info querying is necessary before alerting and I don't think
> that the advertising must be switched off when it's disabled. 

Agreed. So now we'll wait for the spec author to make those changes if
he agrees, too.

/psa



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

[Sergei Golovan]

On 8/10/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Sergei Golovan wrote:
> >
> > This message looks like  but  is better because the
> > recipient may receive result in case of accepted attention or error in
> > case of ignored one. The ability of getting a response even makes
> > disco#info queries unnecessary.
>
> Yes this seems like an acceptable use of IQ to me, though I don't know
> if you really need a response to an attention request.

Yes, I'd like to know if my attention request wasn't ignored by a
recipient's client.

> >
> > I'd not call a responding on disco#info and disco#items query per
> > recipient an overkill.
>
> In this case it seems like overkill to me -- the client needs to keep

You're right that in case of attention support it's an overkill. So,
I'd remove several MUSTs from the XEP. Namely, I don't feel that
disco#info querying is necessary before alerting and I don't think
that the advertising must be switched off when it's disabled. (There
are too many MUSTs in the XEP. I'd remove all of them, actually.)

-- 
Sergei Golovan

Re: [Standards] stop command for extended presence formats

[Sergei Golovan]

On 8/10/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Someone poked me offlist about an oversight in our specs: XEP-0118 (User
> Tune) includes a way to stop sending tune updates, but there is no such
> mechanism in XEP-0107 (User Mood), XEP-0108 (User Activity), etc. This
> seems like a helpful feature and something that we forgot to add to the
> mood/activity/etc. specs, so I think it's something we should look into
> adding (i.e., by sending an empty root element for the appropriate
> namespace, such as  or ).

May be it's better to simply delete a correspondent published item?

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

[Peter Saint-Andre]

Sergei Golovan wrote:
> On 8/9/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> Sergei Golovan wrote:
>>> On 8/9/07, XMPP Extensions Editor <[EMAIL PROTECTED]> wrote:
 Version 0.1 of XEP-0224 (Attention) has been released.
>>> I'd like to comment this version little bit:
>>>
>>> 1) Headline messages are not "normal messages which aren't to be
>>> stored offline". They serve another goal (see section 2.1.1 of RFC
>>> 3921) and cannot (or shouldn't?) be a part of any conversation. So, I
>>> think that it's inappropriate to use headline messages for attention
>>> purpose. If the message shouldn't be stored offline then it should use
>>> AMP (XEP-0079) for example.
>> I think that attention messages should not be sent with a , but
>> should be a standalone message of type='headline', like so:
>>
>> >  to='[EMAIL PROTECTED]/home'
>>  type='headline'>
>>   
>> 
> 
> This message looks like  but  is better because the
> recipient may receive result in case of accepted attention or error in
> case of ignored one. The ability of getting a response even makes
> disco#info queries unnecessary.

Yes this seems like an acceptable use of IQ to me, though I don't know
if you really need a response to an attention request.

>>> 3) (Theoretical question) If we look at client capabilities XEP (115)
>>> we may see that it reaches it's purpose if a features list isn't
>>> changed (since the last sent presence at least) and is the same for
>>> all members in the user's roster. Is this "floating feature" (which
>>> can be switched on/off) really compatible with XEP-0115?
>> If a feature is switched on or off then the sender should send updated
>> caps information.
> 
> I see. But it looks like the client should resend presence on any
> change in features list. 

Exactly right.

> It seems to much for me. 

So don't implement caps.

> I'd like not to
> change features list at all. And the presence of a feature in the list
> should mean "the feature is supported" and not "the feature is turned
> on".

You misunderstand one of the main reasons for entity capabilities. If I
plug in a video camera and can now do Jingle video chat, people may want
to know about that.

>> If a feature is enabled or disabled on a per-recipient basis, then I
>> agree that it may not make sense to include it in the caps data.
>> However, I think it is better in this case and maybe in other (or most)
>> cases to include the attention namespace in the caps data and simply
>> ignore the attention request on the client side if the sender is not
>> allowed to poke the user in this way. Changing the disco#info results on
>> a per-recipient basis seems like overkill.
> 
> I'd not call a responding on disco#info and disco#items query per
> recipient an overkill.

In this case it seems like overkill to me -- the client needs to keep
track of who can even know that my client supports the attention
protocol. Why bother? Just filter it out on the client side. After all,
another client could send you attention requests even if your client
says that it doesn't support the protocol.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

[Standards] stop command for extended presence formats

[Peter Saint-Andre]

Someone poked me offlist about an oversight in our specs: XEP-0118 (User
Tune) includes a way to stop sending tune updates, but there is no such
mechanism in XEP-0107 (User Mood), XEP-0108 (User Activity), etc. This
seems like a helpful feature and something that we forgot to add to the
mood/activity/etc. specs, so I think it's something we should look into
adding (i.e., by sending an empty root element for the appropriate
namespace, such as  or ).

Objections?

/psa




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

[Sergei Golovan]

On 8/9/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Sergei Golovan wrote:
> > On 8/9/07, XMPP Extensions Editor <[EMAIL PROTECTED]> wrote:
> >> Version 0.1 of XEP-0224 (Attention) has been released.
> >
> > I'd like to comment this version little bit:
> >
> > 1) Headline messages are not "normal messages which aren't to be
> > stored offline". They serve another goal (see section 2.1.1 of RFC
> > 3921) and cannot (or shouldn't?) be a part of any conversation. So, I
> > think that it's inappropriate to use headline messages for attention
> > purpose. If the message shouldn't be stored offline then it should use
> > AMP (XEP-0079) for example.
>
> I think that attention messages should not be sent with a , but
> should be a standalone message of type='headline', like so:
>
>   to='[EMAIL PROTECTED]/home'
>  type='headline'>
>   
> 

This message looks like  but  is better because the
recipient may receive result in case of accepted attention or error in
case of ignored one. The ability of getting a response even makes
disco#info queries unnecessary.

> > 3) (Theoretical question) If we look at client capabilities XEP (115)
> > we may see that it reaches it's purpose if a features list isn't
> > changed (since the last sent presence at least) and is the same for
> > all members in the user's roster. Is this "floating feature" (which
> > can be switched on/off) really compatible with XEP-0115?
>
> If a feature is switched on or off then the sender should send updated
> caps information.

I see. But it looks like the client should resend presence on any
change in features list. It seems to much for me. I'd like not to
change features list at all. And the presence of a feature in the list
should mean "the feature is supported" and not "the feature is turned
on".

>
> If a feature is enabled or disabled on a per-recipient basis, then I
> agree that it may not make sense to include it in the caps data.
> However, I think it is better in this case and maybe in other (or most)
> cases to include the attention namespace in the caps data and simply
> ignore the attention request on the client side if the sender is not
> allowed to poke the user in this way. Changing the disco#info results on
> a per-recipient basis seems like overkill.

I'd not call a responding on disco#info and disco#items query per
recipient an overkill. Moreover, if a response to a disco#items
contains items it's necessary to put a correct JID to them (a real JID
for ordinary recipient, and the conference JID for a groupchat
recipients).

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

[Peter Saint-Andre]

Sergei Golovan wrote:
> On 8/9/07, XMPP Extensions Editor <[EMAIL PROTECTED]> wrote:
>> Version 0.1 of XEP-0224 (Attention) has been released.
> 
> I'd like to comment this version little bit:
> 
> 1) Headline messages are not "normal messages which aren't to be
> stored offline". They serve another goal (see section 2.1.1 of RFC
> 3921) and cannot (or shouldn't?) be a part of any conversation. So, I
> think that it's inappropriate to use headline messages for attention
> purpose. If the message shouldn't be stored offline then it should use
> AMP (XEP-0079) for example.

I think that attention messages should not be sent with a , but
should be a standalone message of type='headline', like so:


  


The usage with a  seems odd to me for the reason you point to:
the headline breaks the context of the chat session.

> 2) Since advertising of attention feature is supposed to depend on a
> recipient (and even on time since it can be turned on/off) it looks
> like any compliant client should make a disco#info query before ANY
> attention message sent. Isn't it an overkill?
> 
> 3) (Theoretical question) If we look at client capabilities XEP (115)
> we may see that it reaches it's purpose if a features list isn't
> changed (since the last sent presence at least) and is the same for
> all members in the user's roster. Is this "floating feature" (which
> can be switched on/off) really compatible with XEP-0115?

If a feature is switched on or off then the sender should send updated
caps information.

If a feature is enabled or disabled on a per-recipient basis, then I
agree that it may not make sense to include it in the caps data.
However, I think it is better in this case and maybe in other (or most)
cases to include the attention namespace in the caps data and simply
ignore the attention request on the client side if the sender is not
allowed to poke the user in this way. Changing the disco#info results on
a per-recipient basis seems like overkill.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

[Sergei Golovan]

On 8/9/07, Jakob Schroeter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thursday August 9 2007, Sergei Golovan wrote:
> > 3) (Theoretical question) If we look at client capabilities XEP (115)
> > we may see that it reaches it's purpose if a features list isn't
> > changed (since the last sent presence at least) and is the same for
> > all members in the user's roster. Is this "floating feature" (which
> > can be switched on/off) really compatible with XEP-0115?
>
> I'd say yes, the receiving client should re-disco or use a previously cached
> caps hash.

The problem is which hash to include into a presence packet. It should
be different for different recipients. But there's only one presence
packet (usually).

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

[Jakob Schroeter]

Hi,

On Thursday August 9 2007, Sergei Golovan wrote:
> 3) (Theoretical question) If we look at client capabilities XEP (115)
> we may see that it reaches it's purpose if a features list isn't
> changed (since the last sent presence at least) and is the same for
> all members in the user's roster. Is this "floating feature" (which
> can be switched on/off) really compatible with XEP-0115?

I'd say yes, the receiving client should re-disco or use a previously cached 
caps hash.

Jakob


signature.asc
Description: This is a digitally signed message part.

Re: [Standards] NEW: XEP-0224 (Attention)

[Sergei Golovan]

On 8/9/07, XMPP Extensions Editor <[EMAIL PROTECTED]> wrote:
> Version 0.1 of XEP-0224 (Attention) has been released.

I'd like to comment this version little bit:

1) Headline messages are not "normal messages which aren't to be
stored offline". They serve another goal (see section 2.1.1 of RFC
3921) and cannot (or shouldn't?) be a part of any conversation. So, I
think that it's inappropriate to use headline messages for attention
purpose. If the message shouldn't be stored offline then it should use
AMP (XEP-0079) for example.

2) Since advertising of attention feature is supposed to depend on a
recipient (and even on time since it can be turned on/off) it looks
like any compliant client should make a disco#info query before ANY
attention message sent. Isn't it an overkill?

3) (Theoretical question) If we look at client capabilities XEP (115)
we may see that it reaches it's purpose if a features list isn't
changed (since the last sent presence at least) and is the same for
all members in the user's roster. Is this "floating feature" (which
can be switched on/off) really compatible with XEP-0115?

Cheers!
-- 
Sergei Golovan

Re: [Standards] Username Escaping with Gateway Registration

[Peter Saint-Andre]

Peter Saint-Andre wrote:
> Ian Paterson wrote:
>> XEP-0100 "Gateway Interaction" doesn't, AFAICT, explain whether the
>> username supplied at registration should be the "Legacy Service
>> username" or the "Jabber username". [The difference between these
>> usernames (typically escaping) is explained in section 6.2 (User
>> Addressing).]
>>
>> Can anyone please enlighten me on which username should be used?
> 
> The username used for registration is the LegacyUserAddress. I'll
> clarify this in the spec.

See here:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0100.xml?%40diffMode=u&%40diffWrap=s&r1=1092&r2=1134&u=3&ignore=&k=

TinyURL: http://tinyurl.com/2dxv5j

/psa



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] MUC message moderation

[Mridul Muralidharan]

Hi Peter,

  Please note that the submitted specs are based on what have been 
shipping for 2+ years now - so it is possible that subsequent xep's have 
come out with different or better idioms - we can definitely change for 
the better if it is consistent with the rest of the specs.


I have responses to the rest inline.

Thanks,
Mridul

Peter Saint-Andre wrote:

As promised, here are some questions and comments on the proposed MUC
message moderation specs:

http://www.xmpp.org/extensions/inbox/msg_moderate.html

http://www.xmpp.org/extensions/inbox/room_moderator.html


1. I think it makes sense to combine the two specs into one, with
separate sections for the occupant and moderator use cases.




The msg_moderate spec talks about occupant to room interaction - which 
is expected to be fairly stable across various moderation schemes.


room_moderator spec talks about one realization (profile ?) of message 
moderation where room moderators actively take up the role of message 
moderator - and component decides on this based on the role & affiliation.


While keeping the interaction between occupant and room stable, we could 
have other backend moderation interactions satisfying various other 
requirements - the occupant is agnostic to the actual moderation scheme.


Hence the split - since both are logically different functions.



2. What is the rationale for sending out state changes via presence from
the room's JID?

http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state

How will existing clients handle such state notifications?




The intention is for any occupant who does not understand the xep's to 
continue to function without any error - but with reduced functionality 
since they cant request for moderation.
I was not aware of these presence stanza's causing any problems - but we 
could very well change that to message or iq if they satisfy the same 
requirements.


Another alternative could be to discover if the client supports these 
xep's (disco ?) and the usecases and stanza's described in msg_moderate 
are applicable only to those.





I think we need to come up with a generic approach here. Perhaps the
authors of the message moderation proposal could collaborate with the
authors of the MUCOL proposal (not yet submitted)? They use IQs, not
presence.

http://www.wimba.com/labs/mucol/



mucol defines a way to using particular media like whiteboarding. In 
case of message moderation it is not a collaboration between 
participants of the room. The communication is between the 
user/moderator and room so probably we cannot co-relate them.





3. Why is the message sender forced to flag the message as intended for
moderation?

http://www.xmpp.org/extensions/inbox/msg_moderate.html#moderation-state

It seems to me that this forces the client to be smart about the state
of the room. Older clients may not be that smart, and in any case I
think the room (MUC service) can intelligently decide how to handle



The affiliation/role of an occupant which can make use msg_moderate spec 
is of one who does not have voice.
So, existing clients will not be able to send messages to the room 
currently, and they will not be expecting this ability (like no text 
area in client, etc).


This proposal enables these users to participate in the discussion - 
pending approval from moderator.
The intention here is to be explicit about exhibiting the fact that 
occupants are requesting for a moderated message submission - and due to 
the nature of submission, there are additional workflow and client side 
UI aspects which make use of this information.


For example, in our client how this works is like this:

By default if occupant has no voice, the textarea for submitting 
messages is not present. As soon as message moderation is enabled - a 
text area come up, along with a list of submitted messages and their 
status (pending, approved, rejected - with reason).


On submission of a message, it goes into the pending list - and stays 
there until room acts on it after moderator decision (which can be an 
extended amount of time).
So the user known about message moderation being active, and does not 
expect his message to show up in the room until approved.



So the moderation aspect is expected to be explicit - not implicit.
A particular client could hide these if required.


messages without forcing that intelligence on the sender. Also there is
a dependency here for the client to include an 'id' attribute, which
many clients do not. IMHO it would be good to enable the clients to be
fairly dumb in order to participate in a message-moderated MUC.




Use of id is optional.
Without using id, a client may not be able to disambiguate responses to 
two message submissions if they are rapid enough (that is, before 
component responds to both after recieving both).

Normally, this should not happen - hence optional.
Only requirement is - if present, room should ack it in the response.



4. If undelive

Re: [Standards] Jingle: UDP relays

[Thiago Camargo]

UDP Relays are just simple UDP routers.
So you can bind Ports and IPs to the clients from your XMPP servers.
Clients don't need to negotiate directly with Relay Servers(TURN for instance).
XMPP Servers can negotiate and allocate the tunnel to be used by the client.

Check these drafts:

http://www.gliffy.com/publish/1178640/
http://www.gliffy.com/publish/1130091/

Regards,
Thiago

- Original Message -
From: "Peter Saint-Andre" <[EMAIL PROTECTED]>
To: "XMPP Extension Discussion List" 
Sent: Quinta-feira, 9 de Agosto de 2007 14h24min04s (GMT-0300) America/Sao_Paulo
Subject: Re: [Standards] Jingle: UDP relays

Evgeniy Khramtsov wrote:
> Peter Saint-Andre wrote:
> 
>> At the recent XMPP devcon, I talked a bit with Thiago Camargo about NAT
>> traversal and media relays. There are really two separate issues here:
>>
>> 1. Finding and using STUN servers for NAT traversal. This is discussed
>> in XEP-0215.
>>  
>>
> New STUNbis doesn't define "STUN servers". Currently STUNbis is a low
> level protocol which you can use in other protocols such as ICE and TURN.

Correct.

I wonder how long before rfc3489bis is widely implemented. :)

>> However, as Rémi Denis-Courmont has pointed out [2] on the
>> IETF's BEHAVE list, it is not necessary for the relay to be a TURN
>> server. It's great if the relay is a TURN server, but it could be
>> something else -- and the important point is that for the purposes of
>> media relaying it doesn't really matter to the Jingle client whether the
>> relay does TURN or something simpler.
>>  
>>
> I can't agree :) Why do we need a zoo of relay servers? What is it for?

Who said anything about a zoo? Thiago mentioned that there's no real
need for the relay server to be a TURN server, and at least some people
on the BEHAVE list (and elsewhere) seem to agree. But I'll let Thiago
explain the reasoning more fully.

BTW, can you recommend a good open-source a codebase that can be used to
run a STUN server and/or TURN relay?

/psa

Re: [Standards] Username Escaping with Gateway Registration

[Peter Saint-Andre]

Ian Paterson wrote:
> XEP-0100 "Gateway Interaction" doesn't, AFAICT, explain whether the
> username supplied at registration should be the "Legacy Service
> username" or the "Jabber username". [The difference between these
> usernames (typically escaping) is explained in section 6.2 (User
> Addressing).]
> 
> Can anyone please enlighten me on which username should be used?
> 
> I think it would be very useful to specify this in the XEP.

I assume you mean in Example 7 and thereabouts:

http://www.xmpp.org/extensions/xep-0100.html#example-7

The username used for registration is the LegacyUserAddress. I'll
clarify this in the spec.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Jingle: UDP relays

[Peter Saint-Andre]

Evgeniy Khramtsov wrote:
> Peter Saint-Andre wrote:
> 
>> At the recent XMPP devcon, I talked a bit with Thiago Camargo about NAT
>> traversal and media relays. There are really two separate issues here:
>>
>> 1. Finding and using STUN servers for NAT traversal. This is discussed
>> in XEP-0215.
>>  
>>
> New STUNbis doesn't define "STUN servers". Currently STUNbis is a low
> level protocol which you can use in other protocols such as ICE and TURN.

Correct.

I wonder how long before rfc3489bis is widely implemented. :)

>> However, as Rémi Denis-Courmont has pointed out [2] on the
>> IETF's BEHAVE list, it is not necessary for the relay to be a TURN
>> server. It's great if the relay is a TURN server, but it could be
>> something else -- and the important point is that for the purposes of
>> media relaying it doesn't really matter to the Jingle client whether the
>> relay does TURN or something simpler.
>>  
>>
> I can't agree :) Why do we need a zoo of relay servers? What is it for?

Who said anything about a zoo? Thiago mentioned that there's no real
need for the relay server to be a TURN server, and at least some people
on the BEHAVE list (and elsewhere) seem to agree. But I'll let Thiago
explain the reasoning more fully.

BTW, can you recommend a good open-source a codebase that can be used to
run a STUN server and/or TURN relay?

/psa




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0227 (Portable Import/Export Format for XMPP-IM Servers)

[Peter Saint-Andre]

Magnus Henoch wrote:
> Peter Saint-Andre <[EMAIL PROTECTED]> writes:
> 
>> Why does this document specify an XML namespace? It doesn't seem
>> necessary to namespace the content.
> 
> Indeed, not for its own sake; I was thinking about external tools that
> might want to identify the file, or embed it into some other document.

Sure, there's no harm, I was just curious. :)

>> Also the files could get very large (think about export of information
>> for all 250,000+ users of the jabber.org server). In the XMPP Council
>> meeting, Ralph Meijer suggested the use of XInclude to reduce the file
>> size. YMMV. :)
> 
> Hm… that could work just as well as defining a strict directory
> structure.  I guess not all XMPP-IM servers have a complete XInclude
> implementation, but that could be "solved" by a few SHOULD NOTs in the
> XEP, I think.

OK, that makes sense.

Feel free to pull the source from SVN and send me an updated version:

http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0227.xml

Or poke me off-list and I can give you SVN access.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/




smime.p7s
Description: S/MIME Cryptographic Signature

[Standards] Username Escaping with Gateway Registration

[Ian Paterson]

XEP-0100 "Gateway Interaction" doesn't, AFAICT, explain whether the 
username supplied at registration should be the "Legacy Service 
username" or the "Jabber username". [The difference between these 
usernames (typically escaping) is explained in section 6.2 (User 
Addressing).]


Can anyone please enlighten me on which username should be used?

I think it would be very useful to specify this in the XEP.

- Ian

Re: [Standards] NEW: XEP-0225 (Component Connections)

[Peter Saint-Andre]

Tomasz Sterna wrote:
> Dnia 08-08-2007, śro o godzinie 15:11 -0700, Justin Karneges napisał(a):
>> I vote not repeating this mistake.  This means 
>> no 'jabber:component' or such.  The choice should be between
>> 'jabber:client' 
>> and 'jabber:server' for the namespace.  Use a real attribute or
>> element to 
>> indicate component support.
> 
> +1

I don't have a strong preference really. A component feels a bit more
like a client because it is a local connection, plus c2s connections are
simpler than s2s connections. Let's pick one and be done with it. :)

/psa





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] MUC rooms on roster.

[Kevin Smith]

On 3 Aug 2007, at 10:10, Robin Redeker wrote:

Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html


Some people don't like 48, but I don't really know why (apart from it  
depending on iq:private, which'll be upgraded one of these days). To  
me muc rooms seem substantially different from single-entity contacts  
which normally live in a roster.


/K

Re: [Standards] Jingle: UDP relays

[Evgeniy Khramtsov]

Peter Saint-Andre wrote:


At the recent XMPP devcon, I talked a bit with Thiago Camargo about NAT
traversal and media relays. There are really two separate issues here:

1. Finding and using STUN servers for NAT traversal. This is discussed
in XEP-0215.
 

New STUNbis doesn't define "STUN servers". Currently STUNbis is a low 
level protocol which you can use in other protocols such as ICE and TURN.



However, as Rémi Denis-Courmont has pointed out [2] on the
IETF's BEHAVE list, it is not necessary for the relay to be a TURN
server. It's great if the relay is a TURN server, but it could be
something else -- and the important point is that for the purposes of
media relaying it doesn't really matter to the Jingle client whether the
relay does TURN or something simpler.
 


I can't agree :) Why do we need a zoo of relay servers? What is it for?