Re: [Standards] Incorrect example in XEP-0198?

[Edwin Mons]

On 07/05/2021 14:33, Kevin Smith wrote:
> On 7 May 2021, at 13:30, Matthew Wild  wrote:
>> On Fri, 7 May 2021 at 12:10, Edwin Mons  wrote:
>>> Hi all,
>>>
>>> I was looking at XEP-0198, and noticed something odd in Example 6.
>>> Shouldn't that have been a stream error instead, as the text above
>>> states? If so, will send out a PR.
>> Which is correct? The text or the example? While I was originally
>> inclined to agree that this should be a stream error, it should be
>> noted that section 6 "Error Handling" states:
>>
>>  "If an error occurs with regard to an  or 
>> element, the server MUST return a  element."
>>
>> and
>>
>>  "Stream management errors SHOULD be considered recoverable; however,
>> misuse of stream management MAY result in termination of the stream."
>>
>> It's relevant in the context that a stream error will terminate the
>> session (such that it can't be resumed).
>>
>> I don't feel strongly either way.
> The text in question mentions wanting the connection terminated, which 
> suggests stream error is right (which also seems logically sound to me).
>
> "If a server receives a second  element it SHOULD respond with a 
> stream error, thus terminating the client connection.”

This was indeed how I interpreted the text and am inclined to implement.

Edwin

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Incorrect example in XEP-0198?

[Edwin Mons]

Hi all,

I was looking at XEP-0198, and noticed something odd in Example 6.
Shouldn't that have been a stream error instead, as the text above
states? If so, will send out a PR.

Edwin


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] xep-0313 missing features

[Edwin Mons]

Why would it not be allowed?  The only confusing thing there would be if
your (possibly server-mandated) page size is smaller than the number of
items between before and after, as before and after have conflicting
indicators of which part of the items you'd want to receive.

Edwin



On 05/03/2018 12:11, Lazar Otasevic wrote:
> Kevin says we can :) I asked him to clarify... we'll see.
>
> On Mon, Mar 5, 2018 at 11:45 AM, Philipp Hörist  > wrote:
>
>
>
> You can already fill holes with the current spec, by
> specifying both  and  on the RSM query can’t
> you? If that doesn’t obviously follow from the text, that’s
> something we should clarify.
>
>
>
> No i dont think you can do that. You can either specify 
> OR .
> RSM is for going one page further or backwards with  and
>  inside a already filtered result, you cannot filter the
> result again with upper and lower limits.
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> 
> Unsubscribe: standards-unsubscr...@xmpp.org
> 
> ___
>
>
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0392: Consistent Color Generation - Issues using JID

[Edwin Mons]

On 08-12-17 16:03, Sam Whited wrote:
> On Fri, Dec 8, 2017, at 08:17, Marcel Waldvogel wrote:
>> As JIDs are supposed to be case-preserving, I would expect several
>> implementations do not downcase them first.
> This is incorrect. Per RFC 7622 the localpart of a JID uses the
> UsernameCaseMapped profile of PRECIS defined in RFC 8265 which requires
> use of the Unicode toLower operation, the domainpart of course follows
> normal IDNA2008 rules, and the resourcepart uses the Nickname profile of
> PRECIS defined in RFC 8266 which also uses toLower.

The last bit isn't exactly true.  A resourcepart is an OpaqueString
profile of the FreeformClass.  7622 § 3.4.1 suggests that applications
might use a narrower definition, but that's not enforced by either
XEP-0045 or XEP-0392, is it?

Edwin


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Soliloquy (self-message) routing rules (RFC6121, XEP-0280)

[Edwin Mons]

On 20/03/2017 16:22, Georg Lukas wrote:
> Hi,
>
> sometimes IM users want to talk to themselves, e.g. to send a URL from
> one device to another, or to take notes. In systems like Slack this is
> recognized and the self-message area is provided as a draft board.
>
> In modern XMPP (6121+Carbons/MAM), messages-to-self are always delivered
> twice(*), breaking this usage pattern.
>
> (*) Except for M-Link, which apparently does "the right thing" in
> violation of the RFC.

Except it follows core routing rules as it should, and I merely
misunderstood your problem in xsf@.  It will generate a normal message
delivery as per core routing rules, but will not generate a carbon,
because delivery has already occurred due to normal rules.

Edwin

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] BIND 2.0 and resource binding

[Edwin Mons]

Hi all,

We discussed resource binding in BIND 2.0 at the summit, and more
specifically, user requested resources.  Arguments for and against
allowing these have been made, and rough consensus has been reached that
we want to have a client-unique long-term identifier in the bound
resource, and add a server generated identifier to it.  The format
suggested is as follows:

/

Using / as a separator is open for discussion, but seems like a natural
choice.

The client-unique-id MUST be a UUID (type 4?).  Using a single defined
ID generation algorithm will ensure the resource can't be used for
client fingerprinting.

Open to debate, either:
* client-unique-id MUST be provided.  If the client wishes not to be
uniquely identified between sessions, it should generate a new one on
every bind; or
* client-unique-id MAY be omitted, in which case the server will
generate a random one.


Edwin


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed DTD fixes

[Edwin Mons]

On 30/08/16 20:23, Kevin Smith wrote:
> On 30 Aug 2016, at 18:47, Steve Kille  wrote:
>> Edwin,
>>
>>> Our DTD seems to reject the vast majority of our XEPs.  In part, this is
>>> because there are true mistakes in XEPs – e.g.,  where the author 
>>> actually
>>> should've used  – which aren't converted to the expected HTML, and
>>> in part because the DTD is too strict.  I have just submitted a proposed DTD
>>> change at https://github.com/xsf/xeps/pull/242 that will address (most of)
>>> the latter.
>>>
>>> Thoughts?
>> This seems very helpful.
> Yes, I merged it immediately

Thanks.

>>  I am using an XML editor that enforces compliance to DTD (oXygen), and I 
>> think it would be generally desirable to have all XEPs follow the DTD.
>> Perhaps Travis should do a check?
> We can, if we take care to only validate the modified XEPs, not the whole 
> suite, but there’s a significant danger that we’ll discourage patches for any 
> XEP that doesn’t match the DTD, as folks wouldn’t be able to submit changes 
> without fixing up the other issues, be they either in the XEP or the DTD, so 
> unless someone wants to resolve the remaining issues (ideally for the XSD as 
> well, but at least in the DTD) it’s not clear that it’s the best thing (it’s 
> not clear that it’s not, either).

I will at one point look at the XSDs.  But for starters, none of our
XEPs declare the xmlns on their roots, that's why not even one XEP will
validate against it.  Once that hurdle is passed, I'm sure many other
problems will surface, such as the obviously incorrect data types of
//header/revision/initials and //header/number.

> I wonder if we could run pre-patch vs post-patch tests for the modified XEP, 
> and only fail if it passed before and now fails, so that modifications to a 
> XEP that doesn’t pass the DTD at the moment get a free pass. Not sure I’d 
> much like to be the one to script that, though.

The free pass idea sounds good to me.

Edwin

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed DTD fixes

[Edwin Mons]

Hi,

Our DTD seems to reject the vast majority of our XEPs.  In part, this is
because there are true mistakes in XEPs – e.g.,  where the author
actually should've used  – which aren't converted to the expected
HTML, and in part because the DTD is too strict.  I have just submitted
a proposed DTD change at https://github.com/xsf/xeps/pull/242 that will
address (most of) the latter.

Thoughts?

Edwin

P.S.: don't get me started on the XSD - it will validate exactly 0 of
our documents, because we never even declare the xmlns on the root elements.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] prettify.{css, js}, Was: proposal to remove Managing Multiple IBB Sessions from XEP-0261

[Edwin Mons]

On 24/02/16 10:01, Goffi wrote:
>
> That's off topic, but it seems that prettify.js is missing on the new server, 
> as the examples in the XEP are not colored.

Off-topic, but a valid remark.  I just fixed that.

Edwin

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: References

[Edwin Mons]

On 11-02-16 15:53, Kevin Smith wrote:
> Hi Goffi,
>
> On 8 Feb 2016, at 11:20, Goffi  wrote:
>> Le vendredi 5 février 2016, 15:52:36 XMPP Extensions Editor a écrit :
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>>
>>> Title: References
>>>
>>> Abstract: This document defines XMPP protocol for multi-user chat for text
>>> messages and sharing other information such as images.   The protocol
>>> includes core chatroom features such as room topics and invitations and
>>> defines a strong room control model, including the ability to kick and ban
>>> users, to name room moderators and administrators, to require membership or
>>> passwords in order to join the room.  The protocol aims to maximise use of
>>> standard XMPP building blocks and in particular makes use of PubSub and
>>> MAM.
>> Why do we have the abstract of MIX here instead of the one of references ?
> Incompetence (mine).
>
>>> URL: http://xmpp.org/extensions/inbox/references.html
>> I think this XEP is a good move and will be usefull to complete URIs. I have 
>> some points to discuss:
>>
>> - the XEP talks about MIX and doesn't references it (ha-ha), a link to the 
>> MIX 
>> XEP would help
> Fair.
>
>> - the XEP seems to *only* talk about MIX. Being a work in progress, it would 
>> be nice to show examples with other use cases (PubSub node, MUC).
> Fair.
>
>> - how do we reference something without URI ? A message stanza for instance 
>> ? 
>> How do we specify the id ?
> As Chris later noted, we’re likely to need to define URI schemes for the 
> various things we might want to reference.
>
>> - how begin/end attributes work when there are several bodies ? e.g.: XHTML-
>> IM: how to we references XHTML body ?
> A reasonable question. What do people think?

Or worse, xml:lang alternatives.  I haven't thought of a reasonable
solution, other than an XPath relative to the message element which
would default to "body", but that might be a bit of a monster.
> - how do we use begin/end attributes with  stanza ? e.g. XEP-0277 
> microblog ?
> Same. What would you/other people suggest?

However, such an XPath would solve this issue as well.

Edwin

___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Edwin Mons]

On 19/08/15 23:44, Matthew Wild wrote:
> On 19 August 2015 at 16:44, XMPP Extensions Editor  wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Message Deletion
>>
>> Abstract: This specification defines a method for indicating that a message 
>> should be removed.
>>
>> URL: http://xmpp.org/extensions/inbox/message-deletion.html
>>
>> The XMPP Council will decide in the next two weeks whether to accept this 
>> proposal as an official XEP.
>>
> It's good. I wonder if it would make sense to standardize a way to say
> "This message has been removed"? Both MAM and MUC would benefit from
> such a thing.

I would like some language stating that a service MAY deny / not execute
own message removal even though it advertises the feature, e.g., when
your policy only allows admins to remove messages, especially if a more
generic way would include MAM as well.

Edwin

Re: [Standards] Move CSI to Last Call ("Proposed")

[Edwin Mons]

On 28/07/15 11:05, Dave Cridland wrote:
>
> > Also, why wrap the server notification in a message,
>
> And not using a Nonza? Because most libraries provide a mechanism for
> callbacks matching a given filter only for Stanzas. It's my impression
> as as XMPP client library developer, that we don't want Nonzas to
> trigger callbacks on the client side, as it would increase the
> complexity of XMPP client software stacks.
>
>
> It's very wrong.
>
> Consider a case where the client goes active, then switches to
> inactive but loses connection and recovers via '198. The response -
> which is tightly bound to the session - would indicate that the client
> was inactive, but would arrive on a subsequent connection which is not
> inactive.

If you're doing in-band signalling, you really need to be able to
distinguish signals from actual data.  If you use stanzas, you're making
it very hard for yourself.

Edwin

Re: [Standards] Request HTTP upload slots over XMPP

[Edwin Mons]

On 30/06/15 19:45, Peter Waher wrote:
>
> Hello Daniel
>
>  
>
> You could use XEP-0332, HTTP over XMPP, to do this. To upload content,
> simply perform a PUT, and you can then retrieve it using a normal GET.
>
> http://xmpp.org/extensions/xep-0332.html#PUT
>
>  
>
> If content is small, you can do the transfer in the same request.
> Otherwise, chunked service can be used, or integration with sipub, ibb
> and/or jingle as well, depending on capabilities.
>

So, you're suggesting an in-band transfer mechanism for out-of-band data
transfers?  That sounds a bit wasteful to me.  By the way, how are
updates to 332 progressing?

Edwin

Re: [Standards] MAM and Pubsub

[Edwin Mons]

On 03/02/15 11:05, Goffi wrote:
> G'day,
>
> I have an issue that I mentioned in Brussel to Matthew with using MAM
> (XEP-0313) for PubSub (XEP-0060)/PEP (XEP-0163).
>
> Today to query a PubSub node with MAM, we need to do (according to
> section 4):
>
> 
>node='fdp/submitted/capulet.lit/sonnets'>
> 
>
>
> I don't think it's a good way for the following reasons:
>
> 1) only the "node" attribute allow to know that we are doing a query
> on pubsub. What if someday something called also "node" is used in an
> other XEP ?

Having a node attribute is defined in 313 as specifying you want to
search a pubsub archive instead of another type of archive.  I don't see
the confusion.

>
> 2) pubsub namespace doesn't appear anywhere. In my opinion it's more a
> pubsub request than a MAM request (we query a pubsub service, we just
> want to filter the results), so the pubsub namespace should appear.

No, you're not.  Consider you have a node to which someone has published
with the same item id repeatably, e.g. id='myitem'.  MAM will allow you
to recover previous versions of that particular item, whereas 60 does not.

>
> 3) as we have no pubsub namespace, it is a big problem to delegate it
> with XEP-0355. That means that instead of just delegating pubsub, we
> need to delegate all MAM traffic, including messages, and then send
> them back to server (which is not possible yet). Lot of useless
> traffic and complications.

Letting this one settle in for a bit.  Delegation is a tough problem to
do properly without breaking things, especially if the namespace
delegated has relations to other specs. 

Edwin

[Standards] XEP-0163: listing subscriptions

[Edwin Mons]

Say I have the following situation:

1) a client with interest in mood publishes a PEP node
2) the client will receive said event back from the server

Would Retrieve Subscriptions list a subscription for that node?  And
what about Manage Subscriptions, would that list the owner as a
subscriber?  I'm inclined to say they won't, but 163 is quite vague on that.

Edwin

Re: [Standards] xep-0060 features delete-items and retract-items

[Edwin Mons]

On 08/01/15 14:18, Kurt Zeilenga wrote:
>> On Jan 7, 2015, at 9:27 AM, Ralph Meijer  wrote:
>>
>> On 2015-01-07 16:15, Adrien wrote:
>>> Hi,
>>>
>>> On 01/07/2015 03:42 PM, Edwin Mons wrote:
>>>> Hi all,
>>>>
>>>> XEP-0060 lists both delete-items and retract-items for the same feature,
>>>> .  delete-items was added in the last revision, but it looks
>>>> like an error to me.  I think 7.2 should be revised, and one of the two
>>>> features (likely delete-items) should be removed.
>>> yes you're right. At least that's what I have been told ("delete-items
>>> is the surplus one") when I asked.
>> I forget why it was added in the last version of this XEP, but it surely
>> wasn't missing as mentioned in the changelog, as we had 'retract-items'
>> as a feature for a long time. Reading the text around it, I feel it is
>> confusing, too. I'd rather go with talking about 'retracting items' and
>> 'deleting nodes' thoughout, and not talk about 'deleting items'.
>>
>> I think that many (all?) clients ignore this feature for discovery
>> altogether, so what about making 'delete-items' a thing that servers
>> SHOULD also advertise along with 'retract-items', but have clients
>> depend on 'retract-items' exclusively?
> Personally, I rather not add cruft like this.   Has any server ever 
> advertised this?  Has any client ever relied on this?  And, if it’s only 
> SHOULD, no client can rely on it…  Better, IMO, to just require one 
>  to be advertised per feature.
>

Eh, I've seen delete-items advertised in the wild, because M-Link
advertises it.

Edwin

Re: [Standards] xep-0060 features delete-items and retract-items

[Edwin Mons]

On 07/01/15 18:27, Ralph Meijer wrote:
> On 2015-01-07 16:15, Adrien wrote:
>> Hi,
>>
>> On 01/07/2015 03:42 PM, Edwin Mons wrote:
>>> Hi all,
>>>
>>> XEP-0060 lists both delete-items and retract-items for the same feature,
>>> .  delete-items was added in the last revision, but it looks
>>> like an error to me.  I think 7.2 should be revised, and one of the two
>>> features (likely delete-items) should be removed.
>> yes you're right. At least that's what I have been told ("delete-items
>> is the surplus one") when I asked.
> I forget why it was added in the last version of this XEP, but it surely
> wasn't missing as mentioned in the changelog, as we had 'retract-items'
> as a feature for a long time. Reading the text around it, I feel it is
> confusing, too. I'd rather go with talking about 'retracting items' and
> 'deleting nodes' thoughout, and not talk about 'deleting items'.
>
> I think that many (all?) clients ignore this feature for discovery
> altogether, so what about making 'delete-items' a thing that servers
> SHOULD also advertise along with 'retract-items', but have clients
> depend on 'retract-items' exclusively?
>

That would work for me.

Edwin

[Standards] xep-0060 features delete-items and retract-items

[Edwin Mons]

Hi all,

XEP-0060 lists both delete-items and retract-items for the same feature,
.  delete-items was added in the last revision, but it looks
like an error to me.  I think 7.2 should be revised, and one of the two
features (likely delete-items) should be removed.

Edwin

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  <mailto:j...@edwinm.ik.nu>> 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>
> >> <mailto:d...@cridland.net <mailto:d...@cridland.net>>> wrote:
> >>
> >>
> >> On 3 Dec 2014 21:11, "Kurt Zeilenga"
> mailto:kurt.zeile...@isode.com>
> >> <mailto:kurt.zeile...@isode.com
> <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

[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] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

[Edwin Mons]

On 14/10/14 11:29, Florian Schmaus wrote:
> On 08.10.2014 18:33, XMPP Extensions Editor wrote:
> > This message constitutes notice of a Last Call for comments on
> > XEP-0322 (Efficient XML Interchange (EXI) Format).
>
> > Abstract: This specification describes how EXI compression can be
> > used in XMPP networks.
>
> > URL: http://xmpp.org/extensions/xep-0322.html
>
> > This Last Call begins today and shall end at the close of business
> > on 2014-10-21.
>
> > Please consider the following questions during this Last Call and
> > send your feedback to the standards@xmpp.org discussion list:
>
> > 5. Is the specification accurate and clearly written?
>
> This is more are generic comment on how to deal with this then a EXI
> specific one:
>
> XEP-322 § 2.2.2 "…it sends a setup stanza…" but according to RFC 6120
> § 8 "Three kinds of XML stanza are defined …: , ,
> and ."
>
> So a setup element is not a stanza. I suggest having "stanza" replaced
> by "stream element". There are maybe other wrong uses of "stanza" in
> this XEP (and others).

Related, I think it will be worthwhile to go through the XEP and fix a
few sentences where needed.  E.g. §2.4 has this line in it: " In
addition, the network should allow clients and servers to use not
well-known port because this commeunication involves alternative TCP
port," which took me more than one pass to scan and parse.

Edwin

Re: [Standards] authors and maintainers

[Edwin Mons]

On 12/09/14 17:14, Peter Saint-Andre - &yet wrote:
> On 9/12/14, 9:02 AM, Peter Saint-Andre - &yet wrote:
>
>> Unfortunately, XEP-0155 was only ever used in specs that Ian Paterson
>> worked on (XEP-0136, XEP-0116). All of his protocols were needlessly
>> complex and now we need to deal with the consequences (he disappeared
>> from the XMPP community in ~2007).
>
> This raises the question of what we do about authors who are no longer
> actively participating in the XSF's standards process (I ran into this
> recently with fixes to various Jingle specs). I wonder if it would
> make sense to specify who the maintainer is for any given XEP. For
> example we could add a line at the top of XEP-0166 like so:
>
>Authors: Scott Ludwig, Joe Beda, Peter Saint-Andre,
>Robert McQueen, Sean Egan, Joe Hildebrand
>
>Maintainer: Peter Saint-Andre
>
> Something like this would provide recognition to the original authors
> while indicating who to contact about current issues.
>
+1

Even people not exactly new to the subject are sometimes experiencing
difficulties determining who to contact.

Edwin

Re: [Standards] Cleaning the Wiki

[Edwin Mons]

On 02/09/14 14:08, Kevin Smith wrote:
> On Tue, Sep 2, 2014 at 12:59 PM, edhelas  wrote:
>> Ok, so, to sum-up a little bit the discussion :
>> - We all agree that we need a bugtracker to manage the issues related to
>> each XEP
> I haven't seen much objection to this, as long as it's going to get used.
>
>> - This bugtracker have to run with GIT (because the current XMPP repo is on
>> GIT)
> That would be the most convenient thing.
>
>> - This bugtracker have to be open-source and deployable on a server that the
>> XSF can administrate
> I think there's a strong preference for something we can deploy
> ourselves from some people, and a strong preference for open-source
> from others (possibly a subset, but certainly there are people in camp
> 1 who are less firmly in camp 2).
>
>> - This bugtracker should have some nice issues that we can find on GitHub
>> like the pull-request system
> I don't think this one is a done deal, but pull requests are a model
> that might be made to work.
>
>> - This bugtracker could have a nice "one XEP = one project" system to easily
>> split the issues between the XEP and notify the author (and subscribers)
> I think this is a good idea, but more of the Editors should chime in
> before anything gets settled there.
>
>> - This bugtracker have to be open to anyone using a simple email adress or
>> OpenID
> I think this is heavily desirable.
>
>> We have to agree about what kind of tool we need (with which specific
>> features). Then we will see how to deploy it and use it with the current XSF
>> system :)
> I think looking at gitlab has a lot of merit here, as it seems to tick
> a lot of boxes.
>

If there's (eventual) rough consensus on going gitlab, I'm pretty sure
we'll be able to find a volunteer within the iteam to handle this.

Edwin

Re: [Standards] Proposed XMPP Extension: Buddycloud Channels

[Edwin Mons]

On 28/04/14 18:11, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Buddycloud Channels
>
> Abstract: This document describes a profile and conventions for usage
>   of the PubSub protocol in the context of a new type of 
> communication.
>
> URL: http://xmpp.org/extensions/inbox/buddycloud-channels.html
>
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.
>


Does para 3.2 imply that you should always do the DNS lookup, or should
a client that tries to find a Buddycloud pubsub domain only try this as
a fallback mechanism?  If the former, why do the disco#info at all if an
SRV record is found?  If the latter, how could the results be conflicting?

Edwin

Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery

[Edwin Mons]

On 02/04/14 16:14, Peter Waher wrote:
> Hello Philipp
>
> Thanks for your insightful input. My response to the main item:
>
 section 3.4:
 I don't think IBR should be recommended anymore.
>>> IoT requires automatic account creation. However, I agree it must also be 
>>> secure, from the point of view of the server administrator, especially if 
>>> servers are publically available. I will post a separate XEP soon, that 
>>> provides a secure in-band registration mechanism that can be used by things.
>>>
 section 3.5:
 I would recommend moving the discovery to standard disco#items and to use 
 components (xep-0114) -- those are not much harder to write than standard 
 clients and have many advantages in terms of managability.
>>> Note sure here how this relates to 3.5. Was it a particular step you 
>>> referred to?
>> Basically I'd like to see the method #3 in 3.5 as the one and only way to do 
>> it, with examples. Basically a slightly expanded version of the "determining 
>> support" section:
>> disco#items to the server
>> then disco#info to each item to look for something which has a 
>> urn:xmpp:iot:discovery.
>>
>> xep-0114 style components are just a very convenient way to do this in most 
>> server implementation, but I assumed that you had implemented this using a 
>> registry which was running over c2s. So I mixed up implementation comments 
>> and protocol comments :-/
>>
>> I don't have a strong opinion whether that should be done before accepting 
>> it or afterwards. Might be handy to pretend the other methods never existed.
> Ok. I will certainly have a look at the Jabber Components Protocol 
> (XEP-0114). Even though it is historical, it looks promising. Is there any 
> more recent information available than 
> http://xmpp.org/extensions/xep-0114.html?
>
> One of the mayor problems is that in IoT architecture, we can in many cases 
> not choose the XMPP server. In some cases we do, but not in the most 
> important cases where for instance large operators or companies already have 
> their XMPP server chosen (their own in many cases). Since the XMPP server has 
> already been chosen by the operator in these cases, we need a solution that 
> can work regardless of XMPP server used.
>
> This does not mean XEP-0114 is not a good idea to use, especially if 
> available. The problem is, this cannot be guaranteed. I will most certainly 
> explore this. However, is it possible that we do this during experimental 
> phase? This gives me some time to investigate how widespread the support for 
> XEP-0114 in the XMPP servers chosen for us is. It will also give us some 
> feedback if this can be said to be the main option, or a supplementary option 
> to use.


You seem to confuse Historical with Deprecated.  Although the XEP is
historical, the status is active.  Furthermore, all servers I have used
so far support XEP-0114: this is a core feature of most implementations.

Edwin

Re: [Standards] XSF membership application period Q2 2014

[Edwin Mons]

On 05/03/14 12:30, Alexander Gnauck wrote:
>
> I have setup the membership application Wiki page for the application
> period Q2 2014
>
>  
>
> Applications are encouraged from developers and others who are
> actively involved in the Jabber/XMPP community. To apply, create a
> page about yourself on the Wiki:
>
> http://wiki.xmpp.org/web/Membership_Applications_Q2_2014
>
>  
>
> If you don’t have a wiki account, send your full name, preferred
> nickname and email address to me or one of the other Sysops:
>
> http://wiki.xmpp.org/index.php/Sysops
>
>

The link to the sysops is incorrect.  It should be:
http://wiki.xmpp.org/web/Sysops

Cheers,
Edwin