RE: [Standards] XEP-0047 (Flow rate control for IBB)

2007-07-19 Thread Chris Mullins
Our client, SoapBox Communicator, makes extensive use of IBB.

We also went with an IQ based IBB mechanism that uses flow control. 

We allow the sender to have a configurable number of IQ Packets to be
in the network (e.g. the sender hasn't yet gotten a response) at a
time, and when that limit is reached, no more data is sent until a
response is received. 

This made it preferable to the message based bytestreams, which had some
major congestion issues around them, especially if the two endpoints
were on very asymmetric connections. 

The IQ Packet we use inherits directly from an IQSetPacket, and looks
more-or-less like:

iq type=set ... 
  data sequence='[Some Integer Value]' 
  streamid='stream this packet is for'
Data Being Sent
  /data
/iq 

--
Chris Mullins

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Saint-Andre
Sent: Thursday, July 19, 2007 7:58 AM
To: XMPP Extension Discussion List
Subject: Re: [Standards] XEP-0047 (Flow rate control for IBB)

William Voorsluys wrote:
 Hello,
 
  But, according to the XEP, it is not allowed to include any inner
XML
  stanza on the iq of type RESULT used as ACK:
 
  iq from='[EMAIL PROTECTED]/balcony'
to='[EMAIL PROTECTED]/orchard'
  type='result' id='ibb1'/

 That's just an example.
 The RFC allows zero or one child element in IQ result stanzas.
 This would work:

 iq from='[EMAIL PROTECTED]/balcony' to='[EMAIL PROTECTED]/orchard'
 type='result' id='ibb1'
   data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'
 /iq
 
 Well, I don't think that XEP-0047 would allow such a response. It is
 not clear in the XEP that a client should reply including a data
 element preserving 'sid' and 'seq'. So, most clients wouldn't do that,
 preventing our implementation to interoperate.
 Am I right?

AFAIK, few clients have implemented IBB. We could definitely update the
spec to reflect this kind of acking, which makes a lot of sense IMHO.

Justin, what say you?

/psa



RE: [Standards] XEP-0045: roomnick case

2007-07-19 Thread Chris Mullins
The underlying problem, I believe, is one that's come up before - resources 
that have semantic meaning are very limiting. 

I think the IDEAL option is MEP:

- The MUC room defines a PubSub Node of the same ID. Everyone in the room is 
listed as a subscriber. Everyone visible in the room is defined as a publisher. 

- You nickname is stored in the PubSub Node. When you change it, it gets pushed 
to everyone. 

The actual push format would probably conform to User Location (XEP-0080) or to 
User NickName (XEP-0172).

I wouldn't be opposed to creating a new RoomNamePrep profile that (on the 
server) checked for duplicate names. The visible portion of the names would 
be left alone for user display, but the server would be normalizing them, and 
checking for (and forbidding) dupes. This profile would probably do: Case 
Folding, KC Normalization, and RLCat checking, and very minimal prohibited 
character checking. I know for us, creating a new stringprep profile is 
trivial, so long as it uses a subset of the StringPrep tables that already 
exist. 

To go one step further, I would like to see room names defined this way as 
well. This means the actual room name ([EMAIL PROTECTED]) would be a GUID, and 
the PubsubNode name would also be that same guid. On that node is the room name 
- complete with spaces, and visible in many language (New User Room, 
Nouvelle Pièce D'Utilisateur, 新しいユ�`ザ�`部屋, etc). 

One of the things I see that frustrates users is creating new rooms - they 
don't know what to name it. I would really like to default to a GUId for the 
room name (guaranteed unique), and a friendly name of Chris's Room or 
Chris's Room 958, but can't due to stringprep considerations. 

I do realize these are breaking changes, and MUC has been awfully stable for a 
long time now. The limitations we're starting to see with MUC could be largely 
solved by tying a PubSub node to it, and moving forward from there. 

--
Chris Mullins

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Saint-Andre
Sent: Thursday, July 19, 2007 1:36 PM
To: standards@xmpp.org
Subject: [Standards] XEP-0045: roomnick case

Currently in XEP-0045, roomnicks are case-sensitive. To be precise
roomnicks are handled according to the Resourceprep profile of stringprep:

http://www.xmpp.org/extensions/xep-0045.html#bizrules-jids

This means that the following roomnicks are all different:

StPeter
stpeter
STPETER

Some people have pointed out that this can be confusing to end users.

We could solve it by applying the Nodeprep profile of stringprep, but
that would forbid things like whitespace and the ' and : characters.
(Naturally, those characters could be escaped using XEP-0106 if desired.)

Thoughts?

/psa