On 08.02.2018 11:39, Guus der Kinderen wrote:
> Thank you for all feedback.
>
> The general consensus appears to be in favor of this change, but that a
> stream error definition should be added.
>
> None of the other RFC-6120-defined conditions appear to be fitting here,
> so I suggest that `undefined-condition` is used.
After a quick look at RFC 6120 § 4.9.3 I also found only
undefined-condition suitable.
> Additionally, we should add an application-specific condition element. I
> suggest to add a single `mismatch` element, qualified by the namespace
> as defined for this feature in the XEP.
It may be a good idea to include the received 'h' value and the send
stanza count in that element. This probably helps debugging. And an
optional human readable text is also always a good idea.
Hence my suggestion would be something like:
<stream:error>
<undefined-condition
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<handled-count-too-high
xmlns='urn:xmpp:sm:3'
h='10'
send-count='8'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
You acknowledged 10 stanzas, but I only send you 8 so far.
Something is odd. Please go fix it.
</text>
</stream:error>
</stream:stream>
> If we do more explicitly define the steam error, then it would be
> fitting to also further specify the stream termination that's now
> defined in the last lines of section 3:
>
> Note that a client SHALL only make at most one attempt to enable
> stream management. If a server receives a second <enable/> element
> it SHOULD respond with a stream error, thus terminating the client
> connection.
>
>
> What would be a fitting error condition here?
We have XEP-0198 § 6's example:
<failed xmlns='urn:xmpp:sm:3'>
<unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</failed>
unexpected-request seems fitting, not sure if we want to define an
application specific condition element, e.g. duplicate-enable, in this case.
> Lastly, section 5 defines another stream termination here:
>
> If the former stream is resumed and the server still has the stream
> for the previously-identified session open at this time, the old
> stream SHOULD be terminated.
>
>
> Is this intended to be a termination without stream error? That might
> cause confusion in the client being terminated.
There shouldn't be an old client session any more, since the old client
has resumed the session. It is nevertheless sensible that the server
terminates the former stream.
How this is done is currently underspecified. I would send a stream
error, ending stream tag and then disconnect the transport layer
connection. I believe that in this case 'conflict' (RFC 6120 § 4.9.3.3)
is an appropriate stream error condition.
- Florian
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
