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
___

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 edi...@xmpp.org 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):

 iq to='pubsub.shakespeare.lit' type='set' id='juliet1'
   query xmlns='urn:xmpp:mam:0' queryid='f28'
 node='fdp/submitted/capulet.lit/sonnets'
 /iq


 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

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,
 retract/.  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

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 ral...@ik.nu 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,
 retract/.  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 
 feature/ to be advertised per feature.


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

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

[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,
retract/.  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:07, Kim Alvefur wrote:
 On 2014-12-04 15:11, Kamil Kisiel wrote:
 On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland d...@cridland.net
 mailto:d...@cridland.net wrote:


 On 3 Dec 2014 21:11, Kurt Zeilenga 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 fin/.
 
  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
 fin/ 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
messagefin//message.  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

[Edwin Mons]

On 04/12/14 18:57, Kamil Kisiel wrote:
 On Thu, Dec 4, 2014 at 9:53 AM, Edwin Mons j...@edwinm.ik.nu
 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
 d...@cridland.net mailto:d...@cridland.net
  mailto:d...@cridland.net mailto:d...@cridland.net wrote:
 
 
  On 3 Dec 2014 21:11, Kurt Zeilenga
 kurt.zeile...@isode.com 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 fin/.
  
   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
  fin/ 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
 messagefin//message.  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 fin/
 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] 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 edhe...@movim.eu 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