Re: [Standards] XEP-0047: IBB

[Fabio Forno]

On Sat, Feb 13, 2010 at 3:26 AM, Peter Saint-Andre  wrote:
> A few comments on XEP-0047...
>
> First, it might be useful if the error for "block size too big" provided
> more detailed information, because right now the recipient can't tell
> the sender what block size would be acceptable (e.g., if the sender
> proposes a block size of 4096 and the recipient returns an error, the
> initiator might then try a block size of 2048 but the receiver might
> still return an error; that seems to require too many round trips). I
> propose that we add an application-specific error condition that
> specifies the preferred block size:
>
>     id='jn3h8g65'
>    to='ro...@montague.net/orchard'
>    type='error'/>
>  
>    
>              block-size='1024'/>
>  
> 

Just noticed that the block size is not really negotiated. When
possible I'm always keen to handle feature negotiation without using
errors, since code remains simpler. So I'd prefer to allow the
responder sending back a smaller block size in the answer and not in
the error. In that way the initiator can start sending blocks with the
received block size, without needing to restart the stream

> Second, if the recipient detects an error with a data packet, the spec
> says that it SHOULD (not MUST) return an error and is silent about the
> number of retries that are appropriate, whether the recipient needs to
> close the session at some point, etc. One option would be to say that
> the recipient MUST return an error and close the session if it detects a
> problem with a data packet. Another would be to more carefully specify
> the retry logic. Do folks on this list have a preference?

What about specifying that the recipient MUST return an error with an
appropriate type? In that way it can specify whether to retry or
close.
Especially with IQs I don't have many use cases for allowing retries,
but I think they could be useful for encrypted ibb with a low traffic.
When reopening a S2S connection it could happen that some IQs are lost
(noticed the problem with some servers) and still being able to retry
could be useful.

-- 
Fabio Forno,
Ooros srl
jabber id: f...@jabber.bluendo.com

[Standards] Some issues in XEP-0106: JID Escaping

[Waqas Hussain]

Guus der Kinderen
pointed
out some problems in XEP-0106 in the JDev chatroom.

Section 1. of the XEP lists nine code points which are forbidden in a node
identifier. The character '\' is not in that list, and is used as the escape
character in the algorithms described in the XEP.

Section 4.3 states:

"In order to maintain as much backward compatibility as possible, partial
> escape sequences and escape sequences corresponding to characters not on the
> list of disallowed characters MUST be ignored."


The sequence '\5c' (corresponding to the character '\') as input to the
escaping algorithm needs to be escaped. But it isn't a partial escape
sequence, and it doesn't correspond to a disallowed character, so the above
text dictates that it not be escaped. This breaks the algorithm. A possible
correction is to refer to the mapping in tables 1 or 2, instead of the list
of disallowed characters.

In section 5.1, table 3, the last four examples 9, 10, 11 and 12 do not
follow section 4.3 exceptions. The '\' characters in those examples MUST not
be escaped, according to section 4.3. Example 12 in that list would be
correct with the above suggested correction to section 4.3.

--
Waqas Hussain