Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Tobias M]

> On 12. Apr 2017, at 16:17, Sam Whited  wrote:
> 
> -1
> 
> I've thought about this some more, and I still don't think it makes
> sense to have a "hints" XEP. In my opinion we should move towards
> obsoleting this XEP.

Which XEPs need changes in response to this? Do the hints get under a different 
namespace?

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Sam Whited]

On Wed, Apr 12, 2017 at 9:20 AM, Tobias M  wrote:
> Which XEPs need changes in response to this? Do the hints get under a
> different namespace?


Just MAM and Carbons, I think. Yes, in my opinion these sorts of
thihngs should be namespaced with the spec that uses them.

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Dave Cridland]

On 12 April 2017 at 15:55, Sam Whited  wrote:
> On Wed, Apr 12, 2017 at 9:20 AM, Tobias M  wrote:
>> Which XEPs need changes in response to this? Do the hints get under a
>> different namespace?
>
>
> Just MAM and Carbons, I think. Yes, in my opinion these sorts of
> thihngs should be namespaced with the spec that uses them.

So, Carbons is the only consumer of  - at least for now. But
 is used by, at least, XEP-0313 and XEP-0136, as well as
(in principle) MUC web logs, offline storage, and so on.

Moreover, hints work well for collecting a set of suggested handling
behaviours under one namespace, such that servers can identify an
unknown hint and potentially log its existence.

So on balance, I think I'm +1 for this to advance.

I'd be interested in Sam's counter-arguments, mind.

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Tobias Markmann]

On Wed, Apr 12, 2017 at 5:14 PM, Dave Cridland  wrote:

> So, Carbons is the only consumer of  - at least for now. But
>  is used by, at least, XEP-0313 and XEP-0136, as well as
> (in principle) MUC web logs, offline storage, and so on.
>
> Moreover, hints work well for collecting a set of suggested handling
> behaviours under one namespace, such that servers can identify an
> unknown hint and potentially log its existence.
>

How is the standardisation of Message Processing Hints to go on? There will
likely be more hints in future. So will this XEP never get Final? Or should
each hint be its own XEP if its used by more than one XEP?

I kind of like small XEPs that deal with one thing and do it well.

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Florian Schmaus]

On 19.04.2017 15:25, Tobias Markmann wrote:
> 
> On Wed, Apr 12, 2017 at 5:14 PM, Dave Cridland  > wrote:
> 
> So, Carbons is the only consumer of  - at least for now. But
>  is used by, at least, XEP-0313 and XEP-0136, as well as
> (in principle) MUC web logs, offline storage, and so on.
> 
> Moreover, hints work well for collecting a set of suggested handling
> behaviours under one namespace, such that servers can identify an
> unknown hint and potentially log its existence.
> 
> 
> How is the standardisation of Message Processing Hints to go on? There
> will likely be more hints in future. So will this XEP never get Final?

I'm not sure if there will be (much) more hints in the future. Even if
there will be more hints after XEP-0334 got final, I do not see any harm
in adding them to the XEP, mostly because they are just hints and are
usually used together with a "hint-consuming" XEP.

> I kind of like small XEPs that deal with one thing and do it well.

Me too, that's why I like the hints XEP and don't like the idea that
other XEPs should be required to re-invent it.

- Florian



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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Sam Whited]

On Wed, Apr 19, 2017 at 9:29 AM, Tobias M  wrote:
> Having an own XEP for each hint feels a bit over the top.

I agree, let's not do this.

> Moving each hint to the XEP that uses it would lead to duplication of hints 
> or one XEP using
> a hint defined in an otherwise unrelated XEP.

Is there a real case where this is a problem? I agree that duplication
might not be nice, but if it's eg. duplication between MAM and Message
Archiving, then I think it's fine because we already have a huge
amount of duplication that I'm hopeful we can one day fix by
deprecating one of them. If it's duplication between two different
things that should coexist, then maybe that's an actual problem that
needs solving, but I don't think it's actually a problem right now.

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Sam Whited]

On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland  wrote:
> I'd be interested in Sam's counter-arguments, mind.

- Discoverability: if  or  or whatever is only
used from carbons, why do I have to click through to a different long
XEP to find the one hint that I care about while I'm implementing
carbons?
- Editing: In future, how do we define new hints if this becomes
final? Add them to a final document? A registry? If a registry is
created, can it have normative language if new hints need it? A hints2
document?

In general, these are just simple enough, small enough, and necessary
enough that I think they should be defined in carbons or MAM or
wherever. I vaguely agree that it could be nice to re-use
 between XEPs, but I don't think it's an actual problem
except between MAM and Message Archiving (and as far as I'm concerned
we need to deprecate Message Arhciving and stop confusing people when
the community recommendation is MAM, so that's a no-issue for me).

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Dave Cridland]

On 19 April 2017 at 15:52, Sam Whited  wrote:
> On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland  wrote:
>> I'd be interested in Sam's counter-arguments, mind.
>
> - Discoverability: if  or  or whatever is only
> used from carbons, why do I have to click through to a different long
> XEP to find the one hint that I care about while I'm implementing
> carbons?

I've no objection to a note in Carbons (say) that points to a/the hints XEP.

> - Editing: In future, how do we define new hints if this becomes
> final? Add them to a final document? A registry? If a registry is
> created, can it have normative language if new hints need it? A hints2
> document?
>

I don't really mind where new hints are defined. I'd like them to end
up in the same namespace, however. I'd welcome the philosophical
argument about whether adding new hints to an existing hint namespace
is countenanced by the church, though.

> In general, these are just simple enough, small enough, and necessary
> enough that I think they should be defined in carbons or MAM or
> wherever. I vaguely agree that it could be nice to re-use
>  between XEPs, but I don't think it's an actual problem
> except between MAM and Message Archiving (and as far as I'm concerned
> we need to deprecate Message Arhciving and stop confusing people when
> the community recommendation is MAM, so that's a no-issue for me).

What about MUC web logs?

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

Re: [Standards] [Council] Council Meeting Minutes April 5th 2017

[Sam Whited]

On Thu, Apr 20, 2017 at 3:47 AM, Dave Cridland  wrote:
> What about MUC web logs?

Presumably if they're not using some custom API they have to support
parsing MUC messages with a separately namespaced child anyways, so
they can parse the hint regardless of what the namespace is.
Admittedly, it would be annoying if they had to parse two hints, but
that's another reason why we should deprecate Message Archiving.

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