Re: [Standards] Proposed XMPP Extension: Spoiler messages

[Stefan Strigler]

Like



and then



etc...

Greets, Stefan

On Wed, Nov 2, 2016 at 8:40 AM Stefan Strigler <stefan.strig...@gmail.com>
wrote:

> Couldn't we also support trigger warnings within this context in the same
> way?
>
> On Wed, Nov 2, 2016 at 3:33 AM Lance Stout <lancest...@gmail.com> wrote:
>
> The  element can be used to display human readable text via
> the `hint` attribute, so it should be noted that multiple 
> elements could be present with different `xml:lang` values.
>
> It might be worth making the hint text the character data of the
>  element instead of an attribute.
>
>
>
> /Lance
>
> ___
> 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] Proposed XMPP Extension: Spoiler messages

[Stefan Strigler]

Couldn't we also support trigger warnings within this context in the same
way?

On Wed, Nov 2, 2016 at 3:33 AM Lance Stout  wrote:

> The  element can be used to display human readable text via
> the `hint` attribute, so it should be noted that multiple 
> elements could be present with different `xml:lang` values.
>
> It might be worth making the hint text the character data of the
>  element instead of an attribute.
>
>
>
> /Lance
>
> ___
> 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] PubSub Item Publisher

[Stefan Strigler]

Yes, the PR now is just a small fix to what's inherently wrong.

I'd love to see a discussion about a possible config option.

Or maybe I should just create another PR as a proposal too?

So far it seemed like nobody is interested at all.

On Wed, Oct 26, 2016 at 4:13 PM Sergey Dobrov <bin...@jrudevels.org> wrote:

> It still does not answer how to determine from client if pubsub server
> is going to send them. I.e. if I rely on this feature, I want to know in
> advance if a particular service is suitable?
>
>
> On 26/10/2016 14:58, Stefan Strigler wrote:
> > Created a pull request https://github.com/xsf/xeps/pull/267
> >
> > On Fri, Oct 14, 2016 at 6:09 PM Stefan Strigler
> > <stefan.strig...@gmail.com <mailto:stefan.strig...@gmail.com>> wrote:
> >
> > Also I assume that when this feature is enabled retrieving items as
> > described at
> >
> > https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve
> >
> > the response should also contain the publisher with each item. Right?
> > This should probably be added as a note to '7.1.2.3. Item Publisher'.
> >
> > //Stefan
> >
> > On Fri, Oct 14, 2016 at 2:47 PM Stefan Strigler
> > <stefan.strig...@gmail.com <mailto:stefan.strig...@gmail.com>>
> wrote:
> >
> > Hidey ho,
> >
> > XEP-0060 states
> > at
> http://www.xmpp.org/extensions/xep-0060.html#publisher-publish-success-publisher
> that
> >
> > "If configured to do so, the service can include the publisher
> > of the item" as in "" but nothing
> > more about this throughout the document.
> >
> > I assume it's meant as a per service configuration, so either
> > all or no node would include the publisher. And I wondered if it
> > wouldn't make sense to have that (also?) as a per node
> > configuration option. If so, what would/could it look like?
> >
> >  >label='Whether to include the publisher\'s jid
> > with event notifications'>
> >   false
> > 
> >
> > I'd volunteer to add it to the XEP if people see fit.
> >
> > Thanks,
> >
> >   Stefan
> >
> >
> >
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> >
>
>
> --
> With best regards,
> Sergey Dobrov,
> XMPP Developer and JRuDevels.org founder.
> ___
> 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] PubSub Item Publisher

[Stefan Strigler]

Created a pull request https://github.com/xsf/xeps/pull/267

On Fri, Oct 14, 2016 at 6:09 PM Stefan Strigler <stefan.strig...@gmail.com>
wrote:

> Also I assume that when this feature is enabled retrieving items as
> described at
>
> https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve
>
> the response should also contain the publisher with each item. Right?
> This should probably be added as a note to '7.1.2.3. Item Publisher'.
>
> //Stefan
>
> On Fri, Oct 14, 2016 at 2:47 PM Stefan Strigler <stefan.strig...@gmail.com>
> wrote:
>
> Hidey ho,
>
> XEP-0060 states at
> http://www.xmpp.org/extensions/xep-0060.html#publisher-publish-success-publisher
>  that
>
> "If configured to do so, the service can include the publisher of the
> item" as in "" but nothing more about this
> throughout the document.
>
> I assume it's meant as a per service configuration, so either all or no
> node would include the publisher. And I wondered if it wouldn't make sense
> to have that (also?) as a per node configuration option. If so, what
> would/could it look like?
>
> label='Whether to include the publisher\'s jid with event
> notifications'>
>   false
> 
>
> I'd volunteer to add it to the XEP if people see fit.
>
> Thanks,
>
>   Stefan
>
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] PubSub Item Publisher

[Stefan Strigler]

Also I assume that when this feature is enabled retrieving items as
described at

https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve

the response should also contain the publisher with each item. Right?
This should probably be added as a note to '7.1.2.3. Item Publisher'.

//Stefan

On Fri, Oct 14, 2016 at 2:47 PM Stefan Strigler <stefan.strig...@gmail.com>
wrote:

> Hidey ho,
>
> XEP-0060 states at
> http://www.xmpp.org/extensions/xep-0060.html#publisher-publish-success-publisher
>  that
>
> "If configured to do so, the service can include the publisher of the
> item" as in "" but nothing more about this
> throughout the document.
>
> I assume it's meant as a per service configuration, so either all or no
> node would include the publisher. And I wondered if it wouldn't make sense
> to have that (also?) as a per node configuration option. If so, what
> would/could it look like?
>
> label='Whether to include the publisher\'s jid with event
> notifications'>
>   false
> 
>
> I'd volunteer to add it to the XEP if people see fit.
>
> Thanks,
>
>   Stefan
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] PubSub Item Publisher

[Stefan Strigler]

Hidey ho,

XEP-0060 states at
http://www.xmpp.org/extensions/xep-0060.html#publisher-publish-success-publisher
 that

"If configured to do so, the service can include the publisher of the item"
as in "" but nothing more about this
throughout the document.

I assume it's meant as a per service configuration, so either all or no
node would include the publisher. And I wondered if it wouldn't make sense
to have that (also?) as a per node configuration option. If so, what
would/could it look like?


  false


I'd volunteer to add it to the XEP if people see fit.

Thanks,

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

Re: [Standards] [Council] 2016-07-20 Council Meeting

[Stefan Strigler]

Some random thoughts on this discussion from an observer: From a purely
technical point of view I was like "never make this part of 0045, please".
But I think this is what we always got wrong. Not seeing XMPP also as a
whole thing. We know what it is in reality but from a theoretical point of
view it's just the sum of independent little pieces that /might/ add up or
not. But we all know, they are meant to add up. And it only makes sense if
they do. We should continue to embrace that idea a lot more. To point out
the intended way more clearly and not focus on possible deviations that
much.

On Fri, Aug 5, 2016 at 6:27 PM Tobias Markmann 
wrote:

> On Fri, Aug 5, 2016 at 6:01 PM, Holger Weiß 
> wrote:
>
>>
>> I'd be interested in feedback on this.  Personally, I'd still prefer
>> referring to MAM, as I think the client should to be fully aware of the
>> implications of enabling that option, especially in private rooms.  If
>> we ever come up with another archiving XEP that supports XEP-0045,
>> chances are the archiving semantics and access rules will be different.
>> And it should be no problem for clients supporting future XEPs to use
>> new MUC configuration options if necessary.
>>
>> However, if others prefer "roomconfig_enablearchiving", I'll update my
>> PR¹ accordingly.
>>
>
> I changed my mind, use roomconfig_enablemam or whatever.
>
>
>>
>> > So what's the way forward?  Shall I provide an updated PR against
>> > XEP-0045, or against XEP-0313, or something else (e.g., others suggested
>> > putting all XEP-0045 configuration options into a separate registrar's
>> > list)?
>>
>> While I understand how moving the configuration options into a separate
>> document might be nice, I'm probably not the right person to make this
>> happen, and I'd be grateful if this idea wouldn't block the addition of
>> an option to enable MUC MAM.  If people agree with such an option, can
>> we just put it into XEP-0045 until someone moves things around?
>>
>
> Guess XEP-0045 is fine, it already has a pubsub specific config uption, so
> why not MAM too.
> Further things missing in this change though are:
> - possibly adding a status code for this, there is one for public logging
> after all ( 7.2.13 Room Logging ), but this is probably not a requirement
> - a reference to this option in section 13.3 Privacy, it sounds worthy
> enough to mention there
>
> If that's done i'm +1 for the change.
>
> Cheers,
> Tobi
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light

[Stefan Strigler]

2015-12-14 16:16 GMT+00:00 Dave Cridland :

>
>
> No, you cannot have an arbitrary XEP-0045 service also presented over this
> protocol; it has to be a cut-down, especially written service. The result
> is that existing '45 features are lost entirely.
>

The service identifies itself as

 

over disco-info. Not sure where any confusion could come up here.



> Mobile-friendly is fine, mobile-only is not.
>

It is not mobile only, there is absolutely nothing that would prevent a
desktop client from implementing that protocol.


>
> The point of XMPP is extensibility - by blocking off extensibility because
> you don't think the existing cases are important enough, you're also
> blocking off use-cases none of us have thought of.
>

The intention of this proposal is to resemble functionality that's present
in competing products like Whatsapp et al at a level that's as simple as
possible to implement, esp when focusing on clients. Mobile clients, sure.
It is by no means undermining the extensibility of XMPP, all it does is
exposing a reduced set of functionality as found in MUC over its own new(!)
namespace while reusing parts of things found in MUC for ease of
implementation.

It is not meant as a replacement for MUC, nor is it meant to block or stop
any other efforts to come to a more generalized solution to the same
problem. But it is an ad-hoc approach that solves a problem right now. At
the protocol level as implementation wise (since we have one for
MongooseIM). It documents what we actually do. And I don't see where it
does any harm (because it sounds so at times).


Cheers,

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

Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light

[Stefan Strigler]

Hi,

2015-12-14 17:06 GMT+00:00 Tobias M <tmarkm...@googlemail.com>:

>
> On 14.12.2015, at 17:56, Stefan Strigler <stefan.strig...@gmail.com>
> wrote:
>
> if you want to do IQ with members of a room in the context of MUC Light
> you would do so by addressing them directly since there is no concept of
> anonymous or semi-anonymous rooms.
>
>
> True. Forgot about that. So is there also the requirement that every
> member of the light MUC is already subscribed to the presence of the other
> members via their roster? Then it’d make sense to not distribute the
> presence and IQ again through the light MUC, as everybody has the real JIDs.
>

That's out of scope. We could allow to also broadcast presence through a
room (and I have done that actually), but that should not be mandatory. To
find out about someone's presence there might be many approaches like
direct presence, presence subscription, last activity and so on.

Cheers,

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

Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light

[Stefan Strigler]

Tobias,

if you want to do IQ with members of a room in the context of MUC Light you
would do so by addressing them directly since there is no concept of
anonymous or semi-anonymous rooms.

Cheers, Stefan

2015-12-14 16:39 GMT+00:00 Tobias M :

>
> On 14.12.2015, at 17:04, Piotr Nosek 
> wrote:
>
> b) It is a compilation of requirements of mobile chat providers. I can't
> see why being useful only for mobile clients is a reason to treat is as
> useless. It is a common belief amongst many developers that XMPP is not
> very attractive for mobile environments, why can't we make several
> extensions that are specifically mobile-friendly?
> Yes, there is no possibility of sending IQs but the thing is - what
> IQ-based functionality we would need in groupchats? File transfer? It's a
> common practice nowadays to upload files to external storage like Amazon S3
> and then just send a message with a link. (extra benefit: it can get
> archived by MAM).
>
>
> Well, IQ and presence are used for feature discovery in XMPP by the means
> of Entity Capabilities (XEP-115) and Service Discovery (XEP-0030). IQ is
> not only used for starting file-transfers, but also for avatars and vCards.
> Sure, vCards aren’t that common in popular mobile chat apps. However,
> avatars are.
>
> Cheers,
> Tobias
>
> ___
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
>
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0060: be more consistent with reply #106

[Stefan Strigler]

Hey there,

when implementing parts of XEP-0060 I came across a maybe inconsistency
when it's about unsubscribing from a Node (Section 6.2.2 -
http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscribe).

If we'd allow to also have a the resulting subscription element in the
response, the implementation can be kept more generic, you always reply
with the resulting status of the subscription, no matter if it was a
subscribe or an unsubscribe.

Thus my PR at

https://github.com/xsf/xeps/pull/106

I am aware that for unsubscribing the additional information given is
redundant. That's why I changed it to MAY after I first suggested a SHOULD
there.

Regards,

Stefan

Re: [Standards] XEP-0060: be more consistent with reply #106

[Stefan Strigler]

Hi Ralph,

I totally agree, I've been thinking about this as well. It's just that I
consider it too unrealistic to have that prominent XEP changed so
significantly. Maybe I'm wrong?

I brought that up because if you're operating in a controlled environment,
client wise you know what you can rely on, i.e. you know the exact behavior
of your service component.

In general, what's the philosophy being followed at other XEPs? Favor ease
of implementation over conciseness of the protocol or rather the other way
round?



2015-10-05 20:12 GMT+02:00 Ralph Meijer <ral...@ik.nu>:

> On 2015-10-05 10:48, Stefan Strigler wrote:
> > Hey there,
> >
> > when implementing parts of XEP-0060 I came across a maybe inconsistency
> > when it's about unsubscribing from a Node (Section 6.2.2
> > - http://xmpp.org/extensions/xep-0060.html#subscriber-unsubscribe).
> >
> > If we'd allow to also have a the resulting subscription element in the
> > response, the implementation can be kept more generic, you always reply
> > with the resulting status of the subscription, no matter if it was a
> > subscribe or an unsubscribe.
> >
> > Thus my PR at
> >
> > https://github.com/xsf/xeps/pull/106
> >
> > I am aware that for unsubscribing the additional information given is
> > redundant. That's why I changed it to MAY after I first suggested a
> > SHOULD there.
>
> Hey Stefan,
>
> While I appreciate the suggestion, if the goal is to make the
> implementation more consistent, how would you deal with entities that
> don't return that element on the receiving end? Especially given you
> suggest making it optional. I'd say that the potential gains are highest
> for pubsub clients, but if you can't rely on a server giving that
> element always, there's no gain, really. It doesn't even matter that
> much if it is a MAY or SHOULD.
>
> --
> Cheers,
>
> ralphm
>

Re: [Standards] XEP-0313 purge draft

[Stefan Strigler]

Maybe just contact Valerian directly?

2015-09-21 12:11 GMT+02:00 Michael Uvarov :

> Hi,
>
> The link
> https://demo.frenchtouch.pro/valerian.saliou/xmpp/extensions/xep-0313.html
> is dead.
>
> Does anyone has a copy of this draft? It's the MAM with purge extension
> that was rejected.
>
> --
> Best regards,
> Uvarov Michael
>

Re: [Standards] off-server archives with MAM

[Stefan Strigler]

Sounds like a really nice hack. A recombination of presence, disco and MAM
to gain a totally different user experience.

+1 for the idea :)

Not sure where to put this though. How about

XEP-1337 Hacks

:D

2015-04-18 5:24 GMT+02:00 Kurt Zeilenga kurt.zeile...@isode.com:



  On Apr 17, 2015, at 7:57 PM, Peter Saint-Andre - yet pe...@andyet.net
 wrote:
 
  The Message Archive Management spec (XEP-0313) seems to assume that a
 message archive will live on the server where a user has registered an
 account. This raises privacy and security concerns, especially if the
 messages are not encrypted: as a user I might not want all that message
 history on the server in case it gets hacked, and as a server admin I might
 not want the liability of holding all those messages, either. (In fact, as
 someone who runs a very large public IM service, I can assure you that I do
 not want to have all those messages entrusted to me!)
 
  Ideally, to me, my message archive would be stored on a trusted device
 that is under my control (say, a limited-access storage medium that I keep
 in my house). This device could authenticate to my account and advertise
 its existence to my other resources. Using Carbons (XEP-0280) it could
 obtain copies of all the messages I send and receive. When one of my
 messaging devices wants to retrieve message history, it would do so by
 querying this trusted storage device, not the server (which only handles
 messages for purposes of realtime delivery).
 
  I would really like to see the wording in XEP-0313 adjusted to take this
 scenario into account. I am happy to propose text.

 I think MAM should be mostly accessing server maintained archives.   If
 the archives are maintained by some other entity, such as a client under
 the control of a user, some other extension is needed to address the
 particulars of this scenario. For instance, discovery (the advertisement
 you noted above) would be completely different.  I rather not attempt to
 detail this scenario in XEP 313.  I don’t see any particular need to change
 XEP 313 text to enable a client to offer MAM services.  I think that’s
 already allowed.  For instance, Section 7 says “If a server or other entity
 hosts archives and supports MAM queriers…”.

 — Kurt

 
  Peter
 
  --
  Peter Saint-Andre
  https://andyet.com/

Re: [Standards] off-server archives with MAM

[Stefan Strigler]

Oh, my list is missing the carbons of course.

2015-04-18 10:58 GMT+02:00 Stefan Strigler stefan.strig...@gmail.com:

 Sounds like a really nice hack. A recombination of presence, disco and MAM
 to gain a totally different user experience.

 +1 for the idea :)

 Not sure where to put this though. How about

 XEP-1337 Hacks

 :D

 2015-04-18 5:24 GMT+02:00 Kurt Zeilenga kurt.zeile...@isode.com:



  On Apr 17, 2015, at 7:57 PM, Peter Saint-Andre - yet pe...@andyet.net
 wrote:
 
  The Message Archive Management spec (XEP-0313) seems to assume that a
 message archive will live on the server where a user has registered an
 account. This raises privacy and security concerns, especially if the
 messages are not encrypted: as a user I might not want all that message
 history on the server in case it gets hacked, and as a server admin I might
 not want the liability of holding all those messages, either. (In fact, as
 someone who runs a very large public IM service, I can assure you that I do
 not want to have all those messages entrusted to me!)
 
  Ideally, to me, my message archive would be stored on a trusted device
 that is under my control (say, a limited-access storage medium that I keep
 in my house). This device could authenticate to my account and advertise
 its existence to my other resources. Using Carbons (XEP-0280) it could
 obtain copies of all the messages I send and receive. When one of my
 messaging devices wants to retrieve message history, it would do so by
 querying this trusted storage device, not the server (which only handles
 messages for purposes of realtime delivery).
 
  I would really like to see the wording in XEP-0313 adjusted to take
 this scenario into account. I am happy to propose text.

 I think MAM should be mostly accessing server maintained archives.   If
 the archives are maintained by some other entity, such as a client under
 the control of a user, some other extension is needed to address the
 particulars of this scenario. For instance, discovery (the advertisement
 you noted above) would be completely different.  I rather not attempt to
 detail this scenario in XEP 313.  I don’t see any particular need to change
 XEP 313 text to enable a client to offer MAM services.  I think that’s
 already allowed.  For instance, Section 7 says “If a server or other entity
 hosts archives and supports MAM queriers…”.

 — Kurt

 
  Peter
 
  --
  Peter Saint-Andre
  https://andyet.com/

[Standards] script running amok?

[Stefan Strigler]

Hey there!

Found these in hundreds this morning in editors inbox:

From: standards@xmpp.org on Fri Feb  6 09:20:15 2015
Subject: There where errors during the run of
/home/xsf/editor-auto-test/xsf-tools/testscript.py
on 2015-02-06 09:20:14
Cause: The message headers matched a filter rule

Re: [Standards] OTR

[Stefan Strigler]

I see, we're having a fruitful discussion. This was part of the master
plan. ;)

2014-11-17 13:52 GMT+01:00 Winfried Tilanus winfr...@tilanus.com:

 On 11/14/2014 10:25 PM, Genghis Khan wrote:

 Hi,

  Bobs Suicide Letter has a typo an horrible.

 Well, if that is the only typo / strange thing in the language you have
 found, I think I did pretty well, given that English is not my native
 language. ;-)

 Winfried

Re: [Standards] OTR

[Stefan Strigler]

2014-11-07 13:02 GMT+01:00 Winfried Tilanus winfr...@tilanus.com:

 On 11/07/2014 10:55 AM, Dave Cridland wrote:

  Is anyone willing to help work on a XEP to explain how to run OTR over
  XMPP, and catalogue limitations etc?

 Though I am quite flooded with work right now, I am willing to help with
 that project. Ping me to discuss startingpoints etc..


But will you mention http://thealiceandbobsuicide.org ?

[Standards] XEP-0313 v0.2 vs v0.3

[Stefan Strigler]

Hi everbody!

Can someone please enlighten me why the section on archiving messages esp
the requirement to have

  archived by='jul...@capulet.lit' id='28482-98726-73623' /

added to the message got removed at v0.3? I have a use case where this
would be very useful to know...

Thanks, Stefan

Re: [Standards] New feature proposal for XEP-0313: result limiting per JID

[Stefan Strigler]

2014-08-27 12:41 GMT+02:00 Kevin Smith ke...@kismith.co.uk:

 On Wed, Aug 27, 2014 at 10:33 AM, Piotr Nosek
 piotr.no...@erlang-solutions.com wrote:





 Me and colleagues had a discussion on this issue and we think XEP-0313
 could use a new parameter for queries, that will tell the server to return
 only N last messages for every conversation (i.e. remote JID). Example:

 This would certainly work (although whether to include it in 313
 itself is another matter), but is it the best thing to do? It's not
 clear to me whether returning messages to determine if any exist is
 the best, or another query type to fetch all the active JIDs in the
 last X long.


Yes, of course this would also make sense but it would be a totally
different kind of query (and result). And also a typical use case would be
to display a 'preview' of the conversation which would then result in an
additional query. Overall making the lives esp for client developers more
work. But I'm not totally against the extra query approach either.

Re: [Standards] XMPP meetup July 27 in Berlin?

[Stefan Strigler]

Me too!! :)

Am 17.05.2013 um 22:00 schrieb Alexander Gnauck gna...@ag-software.de:

 
 Anyone interested?
 
 absolutely!!!
 
 Alex

Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?

[Stefan Strigler]

This again leads me back to the question whether we should change SHOULD to 
MUST within this paragraph:


If no stream:features/ element is included in the connection 
manager's session creation response, then the client SHOULD send empty request 
elements until it receives a response containing a stream:features/ element.


What comes to my mind at this point why we should NOT change this is because if 
there's a MUST than you can't do this single shot BOSH session creation + 
auth + some foo we've been talking about the Summit (when it came to web 
clients and performance/round trip times).

.Steve


On 08.02.2013, at 18:28, Peter Saint-Andre stpe...@stpeter.im wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 2/8/13 2:37 AM, Winfried Tilanus wrote:
 On 02/07/2013 01:50 PM, Stefan Strigler wrote:
 
 Hi,
 
 Stream features are only provided by non legacy servers which
 might accept legacy auth for backwards compatibility with legacy
 clients. Legacy servers don't know about stream features.
 
 I have been rereading XEP-0078 on this, and you are right: sending 
 stream features is optional in XEP-0078. So legacy servers my not
 send a stream features.
 
 That raises the question: do we need to maintain backward
 compatibility here, or can we skip all references to XEP-0078
 altogether?
 
 I think we can remove the XEP-0078 references. It has been obsolete
 since 2008.
 
 Peter
 
 - -- 
 Peter Saint-Andre
 https://stpeter.im/
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
 iQIcBAEBAgAGBQJRFTXVAAoJEOoGpJErxa2phqwP/iHfzd42WfGlcyMCrKbS7YSe
 7N9ApiOHE6VYGPBorN/sZhrr7/tkrGnlDoZ/6+JF1OLROrJZApLKWUaaM9Yuc++9
 omApHDtAZ9lJwwlf/ETenAomVKK3IGWYtJz2wQWhd+uKrk1+Pfk31COKymiJnIPp
 +ZTXkTPvf4C2G4o8KEqkXzjV2JwaIbrS41KIHVkrXG/kSsgzWVrD77/JTDSdimPM
 jM8iL7sCb37YvjqsgYCimh9dIYYlbPvnV4sLMKNeY1gpwmr4ZkyLf/rFemhX2wjD
 ErcS4YsM2OSccvZbp9hC1h2Lgr6xXtIVBXKJoGqTViMNkbvXGKHgPB72R26Gn3XX
 RS1v96MWuiDyncGgYnG59JbGU7jP8GTlmF758S2zGtgBxhvHE2FtBqjG4OUJwpMM
 0r3xdGxS8EbM7WbnMIUXZtWgnJovEIL8kBj8uMkAquAG5Z/abX5pEbkmm2GqpI1B
 XRg72DDCMPFBGafYV2bNwYP4dn1Lfq2nIdCXaSS4NW/bPDUKc6zhTrzKKn++WkzC
 SMnPU92Md/dV1ppzautltDNc5Ylk71ezSDFBG28hUTmmsgYcqDtcN4oH9sy/Q8fU
 witTjZPguMMQhMcJ+2uPT3kh9PwU3Zl+hxQHRONYlBEhu4kG0+18P/VJHsVzGwPW
 KCo2GYOvKXVwPR0jffVI
 =M81J
 -END PGP SIGNATURE-
 

Re: [Standards] BOSH and legacy auth - do we have to be backwards compatible?

[Stefan Strigler]

OK!

Am 15.02.2013 um 13:14 schrieb Winfried Tilanus winfr...@tilanus.com:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 On 02/08/2013 06:28 PM, Peter Saint-Andre wrote:
 
 Hi,
 
 I think we can remove the XEP-0078 references. It has been
 obsolete since 2008.
 
 Steve, there seem to be no objections. Do you write a patch for it?
 
 Winfried
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAEBCgAGBQJRHiacAAoJEHZ7UH0X6LdcY0UP/jXoDc0thzPy1R9t/Y2h8c2v
 IQnl19YX+81Tkc+TG87mTek0IY3oA0dgu0hQ89qVx3670SZAlkywgV1+hP5NGtkC
 uV3HlzU9ZIYwEJpA0ZCz3SadFN3cES2ZHOc1DZaab6xQ0sAoAVvOAukCxdx4rIr8
 AMRGsCqDfbY0cKpcbkltZNecyiimfF3iHn4UWtSaVFoIPXyezZGWD7qz4HTxhImy
 7djJlKzzz6Y/tN/9Jy4+GyhUV+02MzmzaYAighP1awmD1cbmvEW5Ju3aCXzirkrF
 F1paiv0qabl7S7cNfVXsnQTzwon9yyJFkuTvT/Fjxi1mxUjinHCxptUMO7hG8hbw
 ymEBXVhBHl982o+2EK83mfjA8FQ7Fu9lK9Tksdk37SxnFvZ3JDwTDE67O54fsNDu
 244BPdZihNZjDCQhQAZiFMm1QP6gYwJzdDpM6MSKRwREumUmv76xC454mfAf7/P1
 XT8RhOOv0+qW6BvipMGvy4oh/Nj7QfzwrAu+nB91IPI0yaaNtIoVQSD57aePifVb
 5ZZo1beWeohXMJklgjgD6s5ByZ/1tRFJUi+D52lLsSL814sNsMVspjMcWgvxoMWM
 SBg/vO8wX7fYEW3jnGCUROo3QsH/KcryV8TcZGhfj/yBmLdvAqJWPIomKRlk/VH7
 riPt9r2rbZ6bt904Se7i
 =AVS8
 -END PGP SIGNATURE-
 

Re: [Standards] BOSH and Multiple Streams

[Stefan Strigler]

Hi,

Am 08.02.2013 um 23:55 schrieb Matt Miller linuxw...@outer-planes.net:

 In working on the patch to address HTTP pipelining, I cascaded into section 
 16: Multiple Streams.
 
 Multiple Streams seems to require support for HTTP pipelining, but feels as 
 if it runs afoul of even the basic requirements for HTTP pipelining (not 
 including the SHOULD NOT use pipelining with non-safe or non-indempotent 
 methods).  I have a hard time working out my patch without doing something 
 substantial about Multiple Streams.

As to my understanding Multiple Streams do not require HTTP Pipelining. 
Actually the XEP says that Mulitple Streams might come in handy in case HTTP 
Pipelining is not available.

 Does anyone actually implement this, and depend on its support?  If so, then 
 I think we ought to separate this into its own XEP, and fixing all of the 
 vagueness and ambiguities around it.  If not, then I would STRONG RECOMMEND 
 removing it completely.

Some years ago I ran into an issue where we wanted to deal with multiple XMPP 
session at the same time and due to browser restrictions couldn't create more 
simultaneous BOSH sessions. That's why we came up with this proposal at first 
hand. But then we never had it implemented. 

.Steve

Re: [Standards] BOSH and legacy auth

[Stefan Strigler]

Matt, 

in short words:

On 07.02.2013, at 13:54, Matthew Miller linuxw...@outer-planes.net wrote:

 If I recall correctly, this issue is about what to do when, after 
 authentication, the client sends a restart=true, but the server does not 
 support that (since there is no way to discover the server's version of 
 support for XEP-0206).
No. :D

.Steve

Re: [Standards] BOSH and legacy auth

[Stefan Strigler]

Hi,

On 07.02.2013, at 13:12, Winfried Tilanus winfr...@tilanus.com wrote:

 On 02/06/2013 05:05 PM, Stefan Strigler wrote:
 
 
 regarding the issue listed at
 
 http://wiki.xmpp.org/web/BoshIssues#Stream_Creation:_missing_.3Cstream:features.2F.3E
 
 Is it correct you are addressing an issue that was not mentioned before
 here, or do my notes of the BOSH sprint at summit 13 fail on this one?

It was on the list, we discussed it and I volunteered to provide a patch.

So yes, maybe it was not discussed here but it was discussed at the summit.

 Then, if you are referring to xep-0078 with legacy auth, it is my
 understanding that first a stream is opened and the server still has
 to send a stream features with auth
 xmlns='http://jabber.org/features/iq-auth'/ in it. Then over that
 stream auth is done by iq stanza's. So in that case, the client still
 will get a stream features before authing. So I see no potential
 confusion here.

Stream features are only provided by non legacy servers which might accept 
legacy auth for backwards compatibility with legacy clients. Legacy servers 
don't know about stream features.

.Steve

[Standards] BOSH and legacy auth

[Stefan Strigler]

Hi folks,

regarding the issue listed at

http://wiki.xmpp.org/web/BoshIssues#Stream_Creation:_missing_.3Cstream:features.2F.3E

I'd propose sth the lines of 

%==

If no stream:features/ element is included in the connection manager's 
session creation response, then the client SHOULD send empty request elements 
until it receives a response containing a stream:features/ element. Legacy 
server implementations that are using aforementioned Non-SASL Authentication 
[8] might not send any stream:features/ element at all. Client 
implementations not supporting legacy authentication therefor are advised to 
interpret the SHOULD above as a MUST and wait for a stream:features/ element. 
Otherwise they shouldn't wait at all or wait until a timeout occurs. This 
timeout should not occur much later than within some seconds. 

%==

But still I'm not really happy about it. For supporting some kind of mixed mode 
or both, legacy auth and SASL based authentication there is no real good advice 
to give if you don't know whether the service in question supports 
stream:features or not other the one from above, waiting for a timeout to 
occur. But that'd mean to wait every time you're talking to a server that has 
legacy auth only. Well, just wanted to point this out. If everybody else is 
happy with my proposal then lets just go with it.

.Steve

Re: [Standards] Proposal for Secure Distributed Discovery of JIDs

[Stefan Strigler]

Wouldn't it be an option to not only publish one's JID on behalf of such a 
lookup service but also other information meant to be publicly available like a 
associated buddycloud node e.g.?

Am 07.02.2013 um 01:13 schrieb Tobias Markmann tmarkm...@googlemail.com:

 Hi,
 
 We have been working on a new XEP proposal which aims to solve the following 
 fundermental problem: How to find a JID given some personal information about 
 the person who owns that JID. Jabber users who've just created their 
 accounts, need to populate their roster with the people they are usually in 
 contact with, with as little manual process as possible.
 
 The proposal is similar to what the BlackBerry does with their PIN or 
 WhatsApp with phone numbers. However, our proposal's approach is different 
 because it is more decentralized and general. By making it so, realiability 
 is increased by not having a single-point-of-failure and it also allows for a 
 greater pool of directories. 
 
 On the other hand, in spite of its benefits, a decentralized approach proves 
 to be most challenging in terms of sercurity, privacy, trust, database 
 maintance and scability. 
 
 We have written a rough draft[1] and we seek suggestions of how to tackle 
 those problems.
 
 This is highly experimental work, so nothing is set on stone yet. We would 
 like to encourage everyone to send us their suggestions about how things 
 should or shouldn't be done.
 
 Cheers,
 Jef  Tobi
 
 [1] http://wiki.xmpp.org/web/Secure_Distributed_JID_Discovery

Re: [Standards] Fwd: [Summit] BOSH actions

[Stefan Strigler]

JSJaC doesn't either. And at least the old implementation of ejabberd's 
mod_http_bind didn't as well.

.Steve

Am 04.02.2013 um 22:39 schrieb Steffen Larsen zoo...@gmail.com:

 Just checked strophe, and it does not use it. I'll check some more 
 implementations that uses BOSH for transport. Maybe that would give us an 
 indication.
 
 /Steffen
 
 On Feb 4, 2013, at 10:06 PM, Peter Saint-Andre (psaintan) 
 psain...@cisco.com wrote:
 
 That sounds sensible. 
 
 Sent from mobile, might be terse 
 
 On Feb 4, 2013, at 1:26 PM, Ashley Ward ashley.w...@surevine.com wrote:
 
 It would be great to keep them consistent, but is it worth potentially
 breaking implementations? I think the main problem with accept was that
 the example was inconsistent with the text.
 
 In fact, I very much doubt anyone should be using that option as xmpp
 mandates the use of utf-8, and I doubt anyone's using bosh for anything
 other than xmpp. Perhaps we should just look at getting rid of that
 attribute?
 
 --
 Ash
 
 On 04/02/2013 10:30, Steffen Larsen zoo...@gmail.com wrote:
 
 Cross-posted from the summit list (sorry making noise).
 Here are my small notes to the BOSH action list (embedded).
 
 
 /Steffen
 
 Begin forwarded message:
 
 From: Peter Saint-Andre (psaintan) psain...@cisco.com
 Subject: Re: [Summit] BOSH actions
 Date: February 2, 2013 10:18:01 PM GMT+01:00
 To: XMPP Summit sum...@xmpp.org
 Cc: Bidirectional Streams Over Synchronous HTTP b...@xmpp.org, XMPP
 Summit sum...@xmpp.org
 Reply-To: XMPP Summit sum...@xmpp.org
 
 Maybe it would be better to take the technical discussion to the
 standards@ list?
 
 Sent from mobile, might be terse
 
 On Feb 2, 2013, at 4:32 PM, Steffen Larsen zoo...@gmail.com wrote:
 
 Hey,
 
 Just saw the issue with the accept attribute. How about charset? It is
 currently space separated in the example  (and it also says) - but
 should we not comma separate that like the accept attribute?
 
 Its on 7.2 in http://xmpp.org/extensions/xep-0124.html:
 charsets='ISO_8859-1 ISO-2022-JP'
 -Just my 50 cent
 
 /Steffen
 
 On Feb 2, 2013, at 4:18 PM, Winfried Tilanus winfr...@tilanus.com
 wrote:
 
 Hi all,
 
 I updated the BOSH issues page with the results  and who will be
 writing patches.
 http://wiki.xmpp.org:12480/web/BoshIssues
 
 I only forgot who will be writing the patch for the first issue
 (remove
 Pipelining). Plz check if your name pops up at the correct places and
 ping me if there are any problems!
 
 happy patch-writing!
 
 Winfried
 
 
 

[Standards] XMPP over Websocket vs XEP-0198

[Stefan Strigler]

Hi,

within Section 3.5[1] XMPP over Websocket states that the closing party MUST 
close the XMPP stream if it has been established. With hindsight of page 
transitions within legacy web apps this might not be wanted by the client as it 
might wish to resume the stream by use (abuse?) of XEP-0198 or some other 
technique. 

Now my questions are:

* Is there some other best practice known how to deal with page transitions 
other than XEP-0198?
* Would XEP-0198 be well suited for this scenario?
* Do we need/want to support this scenario after all within this Draft? If not, 
why?

Maybe this could be just one more topic on the summits agenda next week. I've 
seen there's already quite some demand discussing things regarding web related 
topics.

Regards, 

Steve

[1] https://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01#section-3.5

Re: [Standards] storage:* namespaces

[Stefan Strigler]

Am Freitag, den 17.08.2007, 09:50 -0600 schrieb Peter Saint-Andre:

 The following specs use storage:* namespaces:
[...]
 XEP-0145: Annotations
   http://www.xmpp.org/extensions/xep-0145.html
   state: Historical / Active
[...]
 I propose that we write new specs to replace XEP-0048 and XEP-0145, and
 specify that the payloads can be stored in iq:private or pubsub (i.e.,
 using XEP-0223).
[...]
 Objections?

No :)

Cheers, Steve

Re: [Standards] XEP-0124: which error if sid invalid?

[Stefan Strigler]

Hi Mridul,

Am Mittwoch, den 15.08.2007, 19:11 +0530 schrieb Mridul Muralidharan:

 Intermediaries wont send a 404, which is what (i recall) the xep asks 
 httpbind to send back in case of unknown/invalid sid. So we dont need to 
 know the ver in this case (since httpbind assigns sid  not client, this 
 is fine).
 Hence if we get 404 for initial handshake request, it means httpbind is 
 not running on that webserver/ctxroot, if we get 404 for any other 
 request, it means session is not longer valid/exists.
 
 So from what I see, this should not be a problem.
 Or am I missing something here ?

Sure this is a solution as I proposed myself (see my first *). But of
course we should agree on sth and the XEP should be fixed then.

For me it's ok to send a 404 except for the fact that it's not a 100%
clean solution. 

E.g. the resource could have disappeared (reboot/restart...) causing an
intermediary to send a 404. So a client can not be sure if the session
has definitely terminated or if the resource is unavailable temporarily
and it might be ok to retry for some period of time.

Cheers, Steve

 - Mridul
 
  
  Possible fixes that came to my mind:
  
  * Define this to be a special case and demand to send an HTTP error
  condition. Breaks with concept of separating error conditions at the
  protocol level (you can't tell anymore whether the error is HTTP or BOSH
  related).
  
  * Make clients send a 'ver' attribute with every request. Consumes more
  bandwidth.
  
  Cheers, Steve