Re: [Standards] XEP 313 error handling

[Curtis King]

> On Dec 4, 2014, at 10:10 AM, Edwin Mons  wrote:
> 
> If you send back the iq result first, it will not be delayed further by all 
> the result messages.  Why would there be an error during the message stream 
> that would prevent you from returning an otherwise valid 313 response (or in 
> an extreme case terminating the stream and making the point of properly 
> finishing the messages moot?)
> 
> Most error cases will either happen before or at the moment when you actually 
> start to find messages, e.g. authz issues or database issues.  Once you start 
> sending back messages, or know there aren't any for a particular query, you 
> can always present a valid message stream including a fin with an appropriate 
> rsm set a client can use to continue a query should it choose to.  Note that 
> the XEP allows you to return less items than the amount requested.

The issue is in most cases once you know the query will be successful you have 
the messages to send. So, we are saving less than a second. Doesn’t seem much 
of a saving.

ck

Re: [Standards] XEP 313 error handling

[Edwin Mons]

On 04/12/14 18:57, Kamil Kisiel wrote:
> On Thu, Dec 4, 2014 at 9:53 AM, Edwin Mons  > wrote:
>
> On 04/12/14 18:07, Kim Alvefur wrote:
> > On 2014-12-04 15:11, Kamil Kisiel wrote:
> >> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland
> mailto:d...@cridland.net>
> >> >> wrote:
> >>
> >>
> >> On 3 Dec 2014 21:11, "Kurt Zeilenga"
> mailto:kurt.zeile...@isode.com>
> >>  >> wrote:
> >> >
> >> > How does the server, after it has responded to the IQ
> with a type=result stanza, communicate errors in processing the
> query to the client that might subsequently occur.   What if the
> server is unable to send any subsequent stanzas associated with
> the query?  Is the server expected to hold off sending the IQ
> response until it is reasonable assured that no subsequent errors
> will occur?  That is, to the time in which has compiled all the
> stanzas to sends to the client and is ready to put them to XMPP
> stream?
> >> >
> >> > It seems to me that the IQ response really should come
> last so that the server is able to indicate to the client whether
> or not is has successfully completed the request or failed.   If
> sent last, then there’s really no need for a separate .
> >> >
> >> > If the IQ response is not last, there there really needs
> to be some method for the server to indicate that it’s not able to
> provide further results.
> >> >
> >>
> >> I think I agree with everything written here. Sending the
> iq last
> >> would be best, I think, though I appreciate that's likely
> to be a
> >> protocol bump.
> >>
> >> Dave.
> >>
> >> That's how it was specified in version 0.2, it seems it was
> changed to
> >>  in 0.3
> > I remember someone argued very persistently that this change was
> needed
> > because their code had timeouts for iq requests that could
> trigger if
> > there is rate limiting or a slow connection before all the
> messages and
> > the iq-reply was received.
> >
> > Or something.  Personally I prefer having the iq-result sent
> last, it
> > makes client code (Verse in my case) simpler.
> >
>
> I believe that was Joe.  Nowhere in the XEP do I see a requirement
> that
> the server should send back the IQ result (or error) immediately, just
> that it has to answer the IQ, send back messages, and terminate with a
> .  The example seems to hint at sending
> the iq
> result first, but nowhere does this claim you have to send back the iq
> result before making an attempt to generate results internally.  Only
> the examples hint that you should send back the iq result first, and
> indeed that was the intended behaviour as discussed at the summit.
>
> Edwin
>
>
>
> That seems a bit contradictory to me. If you can delay sending the
> result until all the messages have been sent, how does the 
> message solve the problem of timeouts waiting for the result iq? On
> the other hand if you are sending the iq result at the beginning to
> avoid the timeout, how do you indicate an iq error during the message
> stream? It doesn't seem clear what the answer is.

If you send back the iq result first, it will not be delayed further by
all the result messages.  Why would there be an error during the message
stream that would prevent you from returning an otherwise valid 313
response (or in an extreme case terminating the stream and making the
point of properly finishing the messages moot?)

Most error cases will either happen before or at the moment when you
actually start to find messages, e.g. authz issues or database issues. 
Once you start sending back messages, or know there aren't any for a
particular query, you can always present a valid message stream
including a fin with an appropriate rsm set a client can use to continue
a query should it choose to.  Note that the XEP allows you to return
less items than the amount requested.

Edwin

Re: [Standards] XEP 313 error handling

[Kamil Kisiel]

On Thu, Dec 4, 2014 at 9:53 AM, Edwin Mons  wrote:

> On 04/12/14 18:07, Kim Alvefur wrote:
> > On 2014-12-04 15:11, Kamil Kisiel wrote:
> >> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland  >> > wrote:
> >>
> >>
> >> On 3 Dec 2014 21:11, "Kurt Zeilenga"  >> > wrote:
> >> >
> >> > How does the server, after it has responded to the IQ with a
> type=result stanza, communicate errors in processing the query to the
> client that might subsequently occur.   What if the server is unable to
> send any subsequent stanzas associated with the query?  Is the server
> expected to hold off sending the IQ response until it is reasonable assured
> that no subsequent errors will occur?  That is, to the time in which has
> compiled all the stanzas to sends to the client and is ready to put them to
> XMPP stream?
> >> >
> >> > It seems to me that the IQ response really should come last so
> that the server is able to indicate to the client whether or not is has
> successfully completed the request or failed.   If sent last, then there’s
> really no need for a separate .
> >> >
> >> > If the IQ response is not last, there there really needs to be
> some method for the server to indicate that it’s not able to provide
> further results.
> >> >
> >>
> >> I think I agree with everything written here. Sending the iq last
> >> would be best, I think, though I appreciate that's likely to be a
> >> protocol bump.
> >>
> >> Dave.
> >>
> >> That's how it was specified in version 0.2, it seems it was changed to
> >>  in 0.3
> > I remember someone argued very persistently that this change was needed
> > because their code had timeouts for iq requests that could trigger if
> > there is rate limiting or a slow connection before all the messages and
> > the iq-reply was received.
> >
> > Or something.  Personally I prefer having the iq-result sent last, it
> > makes client code (Verse in my case) simpler.
> >
>
> I believe that was Joe.  Nowhere in the XEP do I see a requirement that
> the server should send back the IQ result (or error) immediately, just
> that it has to answer the IQ, send back messages, and terminate with a
> .  The example seems to hint at sending the iq
> result first, but nowhere does this claim you have to send back the iq
> result before making an attempt to generate results internally.  Only
> the examples hint that you should send back the iq result first, and
> indeed that was the intended behaviour as discussed at the summit.
>
> Edwin
>
>
>
That seems a bit contradictory to me. If you can delay sending the result
until all the messages have been sent, how does the  message solve
the problem of timeouts waiting for the result iq? On the other hand if you
are sending the iq result at the beginning to avoid the timeout, how do you
indicate an iq error during the message stream? It doesn't seem clear what
the answer is.

Re: [Standards] XEP 313 error handling

[Edwin Mons]

On 04/12/14 18:07, Kim Alvefur wrote:
> On 2014-12-04 15:11, Kamil Kisiel wrote:
>> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland > > wrote:
>>
>>
>> On 3 Dec 2014 21:11, "Kurt Zeilenga" > > wrote:
>> >
>> > How does the server, after it has responded to the IQ with a 
>> type=result stanza, communicate errors in processing the query to the client 
>> that might subsequently occur.   What if the server is unable to send any 
>> subsequent stanzas associated with the query?  Is the server expected to 
>> hold off sending the IQ response until it is reasonable assured that no 
>> subsequent errors will occur?  That is, to the time in which has compiled 
>> all the stanzas to sends to the client and is ready to put them to XMPP 
>> stream?
>> >
>> > It seems to me that the IQ response really should come last so that 
>> the server is able to indicate to the client whether or not is has 
>> successfully completed the request or failed.   If sent last, then there’s 
>> really no need for a separate .
>> >
>> > If the IQ response is not last, there there really needs to be some 
>> method for the server to indicate that it’s not able to provide further 
>> results.
>> >
>>
>> I think I agree with everything written here. Sending the iq last
>> would be best, I think, though I appreciate that's likely to be a
>> protocol bump.
>>
>> Dave.
>>
>> That's how it was specified in version 0.2, it seems it was changed to
>>  in 0.3
> I remember someone argued very persistently that this change was needed
> because their code had timeouts for iq requests that could trigger if
> there is rate limiting or a slow connection before all the messages and
> the iq-reply was received.
>
> Or something.  Personally I prefer having the iq-result sent last, it
> makes client code (Verse in my case) simpler.
>

I believe that was Joe.  Nowhere in the XEP do I see a requirement that
the server should send back the IQ result (or error) immediately, just
that it has to answer the IQ, send back messages, and terminate with a
.  The example seems to hint at sending the iq
result first, but nowhere does this claim you have to send back the iq
result before making an attempt to generate results internally.  Only
the examples hint that you should send back the iq result first, and
indeed that was the intended behaviour as discussed at the summit.

Edwin

Re: [Standards] XEP 313 error handling

[Kim Alvefur]

On 2014-12-04 15:11, Kamil Kisiel wrote:
> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland  > wrote:
> 
> 
> On 3 Dec 2014 21:11, "Kurt Zeilenga"  > wrote:
> >
> > How does the server, after it has responded to the IQ with a 
> type=result stanza, communicate errors in processing the query to the client 
> that might subsequently occur.   What if the server is unable to send any 
> subsequent stanzas associated with the query?  Is the server expected to hold 
> off sending the IQ response until it is reasonable assured that no subsequent 
> errors will occur?  That is, to the time in which has compiled all the 
> stanzas to sends to the client and is ready to put them to XMPP stream?
> >
> > It seems to me that the IQ response really should come last so that the 
> server is able to indicate to the client whether or not is has successfully 
> completed the request or failed.   If sent last, then there’s really no need 
> for a separate .
> >
> > If the IQ response is not last, there there really needs to be some 
> method for the server to indicate that it’s not able to provide further 
> results.
> >
> 
> I think I agree with everything written here. Sending the iq last
> would be best, I think, though I appreciate that's likely to be a
> protocol bump.
> 
> Dave.
> 
> That's how it was specified in version 0.2, it seems it was changed to
>  in 0.3

I remember someone argued very persistently that this change was needed
because their code had timeouts for iq requests that could trigger if
there is rate limiting or a slow connection before all the messages and
the iq-reply was received.

Or something.  Personally I prefer having the iq-result sent last, it
makes client code (Verse in my case) simpler.

--
Kim "Zash" Alvefur



signature.asc
Description: OpenPGP digital signature

Re: [Standards] XEP 313 error handling

[Kamil Kisiel]

On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland  wrote:

>
> On 3 Dec 2014 21:11, "Kurt Zeilenga"  wrote:
> >
> > How does the server, after it has responded to the IQ with a type=result
> stanza, communicate errors in processing the query to the client that might
> subsequently occur.   What if the server is unable to send any subsequent
> stanzas associated with the query?  Is the server expected to hold off
> sending the IQ response until it is reasonable assured that no subsequent
> errors will occur?  That is, to the time in which has compiled all the
> stanzas to sends to the client and is ready to put them to XMPP stream?
> >
> > It seems to me that the IQ response really should come last so that the
> server is able to indicate to the client whether or not is has successfully
> completed the request or failed.   If sent last, then there’s really no
> need for a separate .
> >
> > If the IQ response is not last, there there really needs to be some
> method for the server to indicate that it’s not able to provide further
> results.
> >
>
> I think I agree with everything written here. Sending the iq last would be
> best, I think, though I appreciate that's likely to be a protocol bump.
>
> Dave.
>
That's how it was specified in version 0.2, it seems it was changed to
 in 0.3

Re: [Standards] XEP 313 error handling

[Dave Cridland]

On 3 Dec 2014 21:11, "Kurt Zeilenga"  wrote:
>
> How does the server, after it has responded to the IQ with a type=result
stanza, communicate errors in processing the query to the client that might
subsequently occur.   What if the server is unable to send any subsequent
stanzas associated with the query?  Is the server expected to hold off
sending the IQ response until it is reasonable assured that no subsequent
errors will occur?  That is, to the time in which has compiled all the
stanzas to sends to the client and is ready to put them to XMPP stream?
>
> It seems to me that the IQ response really should come last so that the
server is able to indicate to the client whether or not is has successfully
completed the request or failed.   If sent last, then there’s really no
need for a separate .
>
> If the IQ response is not last, there there really needs to be some
method for the server to indicate that it’s not able to provide further
results.
>

I think I agree with everything written here. Sending the iq last would be
best, I think, though I appreciate that's likely to be a protocol bump.

Dave.

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

[Christian Schudt]

Hi,

> Receiving  can mean either the 
> user went idle $TIME_STANZA_SENT - 903 seconds or user went offline at that 
> point. You can’t know it solely based on this stanza. You’d require further 
> presence information to resolve the semantic overload.

In my opinion this isn't hard to distingish. If the presence has a show element 
(of value away/xa) it means idle since X seconds. If it is just a plain 
"availble" presence it means "I was last time online X seconds ago".
 
> Furthermore the XEP-0012 data alone has little value for a UI/UX. It in 
> response to an IQ, it requires presence information to know what it means 
> (idle or went offline). Received via presence it request delayed delivery 
> information to know the actual idle time.

If in response to an IQ you know exactly what it means (as specified in 
XEP-0012) without needing presence information:
If you send your IQ to the bare JID it means "went offline" (server responds to 
IQ).
If you send your IQ to the full JID it means "idle" (client responds to IQ).

If in a presence, I think XEP-0256 is clear enough on it.

I agree that XEP-0012 has overloaded semantics, but on the other hand they are 
all related to each other and aren't hard to understand or to implement, where 
as a new XEP (319) would add yet another way to deal with the use cases 
described in 0256 (and 0012). I just don't like the idea of having two XEPs for 
the same use case.

XEP-0256 could be obsoleted/deprecated, if XEP-0319 becomes a standard, but I 
don't know XSF's opinion about that, because it's out there for a long time.

- Christian

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

[Florian Schmaus]

On 04.12.2014 09:14, Tobias Markmann wrote:
> On 04.12.2014, at 00:14, Florian Schmaus  > wrote:
> 
>> BTW was it ever discussed to *simply* extend XEP-12 (and thus XEP-256)
>> with an (optional) 'timestamp' attribute that contains an absolute time
>> value?
> 
> Back then I thought a little about it. But since XEP-0012 has a semantic
> overload which complicates further correct handling in client
> implementations. Receiving 

Re: [Standards] Chat markers and pagination

[Spencer MacDonald]

It is assumed that you either load the last X Messages or you load all of
them.

Typically if you sign in on a client that has no (previous) cache, you
would only download the last few messages e.g. 25 per chat, then the user
can manually download messages prior to that.

Spencer

On Thu, Dec 4, 2014 at 1:50 AM, priya v  wrote:

> How would chat markers work when they are used in the context of
> pagination? Please consider the following use case to get a better
> understanding of my question-
>
> Assume there are 50 messages stored in a user's archive store. Of which a
> marker of type 'delivered' is received for the 25th message. Assume an XMPP
> client queried for the first 10 messages from the user's store.
>
> Should the server send the 25th marker even if the 25th message is not
> sent?
> Messages from 1 to 10 might have been read without any markers being sent.
>
> The spec doesn't talk of cases where markers are used in conjunction with
> RSM. How do we handle such cases?
>

[Standards] Retrieving pubsub items via their IDs + RSM

[Adrien]

Hi guys,

suppose a pubsub service is implementing XEP-0059 and it is configured 
to return a maximum number of 2 items.


Then what should happen when the user wants to retrieve items by 
specifying their IDs?


Case 1:

  

  
  
  
  
  
  

  

What to return here? All the items or only A and B? Does it make sense 
for the service to answer with an embedded  element? Something like 
that maybe:



  A
  B
  19


Case 2:

  

  
  
  
  
  
  

  

We assume that the item indexes are following the alphabetical order (A 
has index 0, B index 2... what to return here? All the items, only A and 
B or only A and E?! What about the  element? Isn't strange if A and 
E are returned (we could not call it a page anymore!)?


Case 3:

  

  
  
  
  
  
  


  2

  

Maybe the answers to cases 1 and 2 are "don't return a set when the 
request specifies the item IDs", but what now if it also explicitly asks 
for a set?


Or do you just say that the client should not be stupid and make 
coherent requests? :)


Many thanks,
Adrien

Re: [Standards] LAST CALL: XEP-0319 (Last User Interaction in Presence)

[Tobias Markmann]

On 04.12.2014, at 00:14, Florian Schmaus  wrote:

> BTW was it ever discussed to *simply* extend XEP-12 (and thus XEP-256)
> with an (optional) 'timestamp' attribute that contains an absolute time
> value?

Back then I thought a little about it. But since XEP-0012 has a semantic 
overload which complicates further correct handling in client implementations. 
Receiving