Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

2017-06-22 22:22 GMT+02:00 Dave Cridland :
> On 22 June 2017 at 21:02, Daniel Gultsch  wrote:
>> If you take a look at example 13 of XEP-0357 there is a
>> publish-options form field called secret which probably counts as an
>> example of 'meta-data'.
>> https://xmpp.org/extensions/xep-0357.html
>> If that XEP wouldn't register that form field a pub service that
>> advertises publish-options would reject it. (Nobody forces the App
>> server to do in fact advertise publish-options. And tbh honest it is
>> highly questionable why push notifications even use pubsub syntax but
>> that's a discussion for another day)
>>
>
> Good spot. Yes, publishing metadata rather than item metadata, then.

Does this mean you want me to change the wording of "it defines
METADATA to be attached to the item" to something else?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0223: Clarification

[Dave Cridland]

On 22 June 2017 at 21:02, Daniel Gultsch  wrote:
> If you take a look at example 13 of XEP-0357 there is a
> publish-options form field called secret which probably counts as an
> example of 'meta-data'.
> https://xmpp.org/extensions/xep-0357.html
> If that XEP wouldn't register that form field a pub service that
> advertises publish-options would reject it. (Nobody forces the App
> server to do in fact advertise publish-options. And tbh honest it is
> highly questionable why push notifications even use pubsub syntax but
> that's a discussion for another day)
>

Good spot. Yes, publishing metadata rather than item metadata, then.

> 2017-06-22 21:52 GMT+02:00 Daniel Gultsch :
>> 2017-06-22 21:42 GMT+02:00 Dave Cridland :
>>> On 22 June 2017 at 20:23, Daniel Gultsch  wrote:
 I went ahead and created a PR reflecting the changes we discussed.

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

 Rendered version is linked from within the PR.
>>>
>>> Thanks for this. This seems mostly reasonable, but I'm concerned by
>>> per-item metadata which I didn't realise you were thinking of.
>>>
>>> Could you perhaps give some examples of what you're thinking here? The
>>> only metadata I care about at present is security labels, and those
>>> (currently) don't have a way of being put in forms.
>>
>> This was copy pasted from here:
>> https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-publish
>>
>> I don't know what metadata means in that context. I'm happy to remove it.
>>
>> cheers
>> Daniel
> ___
> 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-0223: Clarification

[Daniel Gultsch]

If you take a look at example 13 of XEP-0357 there is a
publish-options form field called secret which probably counts as an
example of 'meta-data'.
https://xmpp.org/extensions/xep-0357.html
If that XEP wouldn't register that form field a pub service that
advertises publish-options would reject it. (Nobody forces the App
server to do in fact advertise publish-options. And tbh honest it is
highly questionable why push notifications even use pubsub syntax but
that's a discussion for another day)

2017-06-22 21:52 GMT+02:00 Daniel Gultsch :
> 2017-06-22 21:42 GMT+02:00 Dave Cridland :
>> On 22 June 2017 at 20:23, Daniel Gultsch  wrote:
>>> I went ahead and created a PR reflecting the changes we discussed.
>>>
>>> https://github.com/xsf/xeps/pull/481
>>>
>>> Rendered version is linked from within the PR.
>>
>> Thanks for this. This seems mostly reasonable, but I'm concerned by
>> per-item metadata which I didn't realise you were thinking of.
>>
>> Could you perhaps give some examples of what you're thinking here? The
>> only metadata I care about at present is security labels, and those
>> (currently) don't have a way of being put in forms.
>
> This was copy pasted from here:
> https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-publish
>
> I don't know what metadata means in that context. I'm happy to remove it.
>
> cheers
> Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

2017-06-22 21:42 GMT+02:00 Dave Cridland :
> On 22 June 2017 at 20:23, Daniel Gultsch  wrote:
>> I went ahead and created a PR reflecting the changes we discussed.
>>
>> https://github.com/xsf/xeps/pull/481
>>
>> Rendered version is linked from within the PR.
>
> Thanks for this. This seems mostly reasonable, but I'm concerned by
> per-item metadata which I didn't realise you were thinking of.
>
> Could you perhaps give some examples of what you're thinking here? The
> only metadata I care about at present is security labels, and those
> (currently) don't have a way of being put in forms.

This was copy pasted from here:
https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-publish

I don't know what metadata means in that context. I'm happy to remove it.

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

Re: [Standards] XEP-0223: Clarification

[Dave Cridland]

On 22 June 2017 at 20:23, Daniel Gultsch  wrote:
> I went ahead and created a PR reflecting the changes we discussed.
>
> https://github.com/xsf/xeps/pull/481
>
> Rendered version is linked from within the PR.

Thanks for this. This seems mostly reasonable, but I'm concerned by
per-item metadata which I didn't realise you were thinking of.

Could you perhaps give some examples of what you're thinking here? The
only metadata I care about at present is security labels, and those
(currently) don't have a way of being put in forms.

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

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

I went ahead and created a PR reflecting the changes we discussed.

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

Rendered version is linked from within the PR.

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

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

2017-06-02 10:46 GMT+02:00 Dave Cridland :
> I agree this is the only sane behaviour. I'm not sure what existing
> servers actually do, though.

Prosody and Ejabberd don't advertise that feature at all. Regarding
OpenFire you might have better insight than I do.
My point however is that if we can agree that this was plan for
#publish-options all along then we don't need a new feature for this
as implementations which are not behaving like this are wrong.

I would like to be done with the new feature or existing feature
discussion before I put the work in to create a PR.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0223: Clarification

[Dave Cridland]

On 2 June 2017 at 09:36, Daniel Gultsch  wrote:
> 2017-06-02 10:19 GMT+02:00 Dave Cridland :
>> On 2 June 2017 at 09:14, Daniel Gultsch  wrote:
>>> 2017-05-25 13:20 GMT+02:00 Dave Cridland :
 So you want the outcome to be:

 a) The publish option is known to the server, in which case it is
 treated as a precondition or override as given in the registry.
 b) The publish option is not known to the server, in which case the
 publish is rejected.

 Does that seem about right?
>>>
>>> I didn't take that as an agreement. I thought it was just a
>>> clarification regarding my question.
>>>
>>
>> Ah, sorry, I wasn't clear enough. Yes, that was a proposal that i
>> thought matched your aims.
>>
>>> But if it was indeed an agreement (and nobody else objects) I guess I
>>> can write up a paragraph for XEP-0060.
>>
>> I think that's the ideal first step, yes.
>>
>> I would be curious to explore if it would be worthwhile extracting
>> publish options out into a distinct XEP; this would perhaps depend on
>> whether we were going to have to add a feature for this new?
>> behaviour.
>
>
> Is this new behavior? My original question was 'Is this was
> #publish-options does?' if not how else is #publish-options supposed
> to behave?
>

I agree this is the only sane behaviour. I'm not sure what existing
servers actually do, though.

> IMHO this is the only logical behavior of the already existing
> #publish-options (that's not implemented anywhere?) Otherwise I don't
> think #publish-options servers any purpose at all. I can't request a
> list of available publish-options from the server. And even if I could
> if the behavior is not standardized am I supposed to display the form
> data to the user?
> ___
> 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-0223: Clarification

[Daniel Gultsch]

2017-06-02 10:19 GMT+02:00 Dave Cridland :
> On 2 June 2017 at 09:14, Daniel Gultsch  wrote:
>> 2017-05-25 13:20 GMT+02:00 Dave Cridland :
>>> So you want the outcome to be:
>>>
>>> a) The publish option is known to the server, in which case it is
>>> treated as a precondition or override as given in the registry.
>>> b) The publish option is not known to the server, in which case the
>>> publish is rejected.
>>>
>>> Does that seem about right?
>>
>> I didn't take that as an agreement. I thought it was just a
>> clarification regarding my question.
>>
>
> Ah, sorry, I wasn't clear enough. Yes, that was a proposal that i
> thought matched your aims.
>
>> But if it was indeed an agreement (and nobody else objects) I guess I
>> can write up a paragraph for XEP-0060.
>
> I think that's the ideal first step, yes.
>
> I would be curious to explore if it would be worthwhile extracting
> publish options out into a distinct XEP; this would perhaps depend on
> whether we were going to have to add a feature for this new?
> behaviour.


Is this new behavior? My original question was 'Is this was
#publish-options does?' if not how else is #publish-options supposed
to behave?

IMHO this is the only logical behavior of the already existing
#publish-options (that's not implemented anywhere?) Otherwise I don't
think #publish-options servers any purpose at all. I can't request a
list of available publish-options from the server. And even if I could
if the behavior is not standardized am I supposed to display the form
data to the user?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0223: Clarification

[Dave Cridland]

On 2 June 2017 at 09:14, Daniel Gultsch  wrote:
> 2017-05-25 13:20 GMT+02:00 Dave Cridland :
>> So you want the outcome to be:
>>
>> a) The publish option is known to the server, in which case it is
>> treated as a precondition or override as given in the registry.
>> b) The publish option is not known to the server, in which case the
>> publish is rejected.
>>
>> Does that seem about right?
>
> I didn't take that as an agreement. I thought it was just a
> clarification regarding my question.
>

Ah, sorry, I wasn't clear enough. Yes, that was a proposal that i
thought matched your aims.

> But if it was indeed an agreement (and nobody else objects) I guess I
> can write up a paragraph for XEP-0060.

I think that's the ideal first step, yes.

I would be curious to explore if it would be worthwhile extracting
publish options out into a distinct XEP; this would perhaps depend on
whether we were going to have to add a feature for this new?
behaviour.

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

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

2017-05-25 13:20 GMT+02:00 Dave Cridland :
> So you want the outcome to be:
>
> a) The publish option is known to the server, in which case it is
> treated as a precondition or override as given in the registry.
> b) The publish option is not known to the server, in which case the
> publish is rejected.
>
> Does that seem about right?

I didn't take that as an agreement. I thought it was just a
clarification regarding my question.

But if it was indeed an agreement (and nobody else objects) I guess I
can write up a paragraph for XEP-0060.

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

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

2017-05-25 13:20 GMT+02:00 Dave Cridland :
> On 25 May 2017 at 12:16, Daniel Gultsch  wrote:
>> Small clarification on my own wording:
>>
>> 2017-05-16 19:07 GMT+02:00 Daniel Gultsch :
>>> - If a certain form field is registered with the registry [1] all
>>> server implementations MUST behave according to the specification in
>>> [1].
>>
>> This should read:
>> If a certain form field is registered with the registry [1] AND the
>> pubsub services announces #publish-options as a feature all server
>> implementations MUST behave according to the specification in [1].
>>
>> The reason I want this to be cleared up either on this list or even
>> better in section 7.1.5 of XEP-0060 is that this has the potential to
>> save me a lot of round trips when regularly publishing items to pubsub
>> nodes with a specific access model.
>> Without it I would have to explicitly configure the node every time
>> before I post an item. On the other hand if my assumptions are correct
>> I can publish items on a whim, having the server reject the
>> publication if the access model doesn't match and only in that
>> (probably rare case) configure the node and republish the item.
>
> So you want the outcome to be:
>
> a) The publish option is known to the server, in which case it is
> treated as a precondition or override as given in the registry.

Yes. If a certain publish-option is registered I want the server to
treat as either a a precondition, override or metadata depending on
what is described in the registry.

> b) The publish option is not known to the server, in which case the
> publish is rejected.

In general I do not care how the server handles unregistered options.
However since the list of registered options can grow without the
server knowing about it I guess having the server reject every unknown
option is a consequence of (a).


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

Re: [Standards] XEP-0223: Clarification

[Dave Cridland]

On 25 May 2017 at 12:16, Daniel Gultsch  wrote:
> Small clarification on my own wording:
>
> 2017-05-16 19:07 GMT+02:00 Daniel Gultsch :
>> - If a certain form field is registered with the registry [1] all
>> server implementations MUST behave according to the specification in
>> [1].
>
> This should read:
> If a certain form field is registered with the registry [1] AND the
> pubsub services announces #publish-options as a feature all server
> implementations MUST behave according to the specification in [1].
>
> The reason I want this to be cleared up either on this list or even
> better in section 7.1.5 of XEP-0060 is that this has the potential to
> save me a lot of round trips when regularly publishing items to pubsub
> nodes with a specific access model.
> Without it I would have to explicitly configure the node every time
> before I post an item. On the other hand if my assumptions are correct
> I can publish items on a whim, having the server reject the
> publication if the access model doesn't match and only in that
> (probably rare case) configure the node and republish the item.

So you want the outcome to be:

a) The publish option is known to the server, in which case it is
treated as a precondition or override as given in the registry.
b) The publish option is not known to the server, in which case the
publish is rejected.

Does that seem about right?

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

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

Small clarification on my own wording:

2017-05-16 19:07 GMT+02:00 Daniel Gultsch :
> - If a certain form field is registered with the registry [1] all
> server implementations MUST behave according to the specification in
> [1].

This should read:
If a certain form field is registered with the registry [1] AND the
pubsub services announces #publish-options as a feature all server
implementations MUST behave according to the specification in [1].

The reason I want this to be cleared up either on this list or even
better in section 7.1.5 of XEP-0060 is that this has the potential to
save me a lot of round trips when regularly publishing items to pubsub
nodes with a specific access model.
Without it I would have to explicitly configure the node every time
before I post an item. On the other hand if my assumptions are correct
I can publish items on a whim, having the server reject the
publication if the access model doesn't match and only in that
(probably rare case) configure the node and republish the item.

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

Re: [Standards] XEP-0223: Clarification

[Daniel Gultsch]

Hi,

I also tripped over this today although in a slightly different
context. And my issues are more about publish-options from XEP-0060 in
general rather than XEP-0223 in particular.

My interpretation is as follows.

- publish-options can contain arbitrary form fields.
- If a certain form field is registered with the registry [1] all
server implementations MUST behave according to the specification in
[1].
- The description in [1] "Forms enabling publication with options;
each field must specify whether it defines METADATA to be attached to
the item, a per-item OVERRIDE of the node configuration, or a
PRECONDITION to be checked against the node configuration." is a hint
to other people who might want to register more form fields and NOT a
hint that should ever be displayed to the end user.
- Currently only "pubsub#access_model" is defined with the registrar.
So when the server supports publish-options and I set a publish option
of access_model=whitelist it is guaranteed that all servers will
reject the publication if the access_model is not whitelist
- The behavior of setting a publish-option of persist-items as we can
see in the examples of XEP-0223 is completely unspecified because it
hasn't been registered.

Is this interpretation correct?

cheers
Daniel

[1]: https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-publish

2016-10-21 23:47 GMT+02:00 forenjunkie :
> Hi,
> Maybe its just my impression but it seems there is not much Server support
> for this XEP
>
> Especially #publish-options is missing from a lot of servers.
> Missing as in the server is capable of it but does deliberately not publish
> that feature.
>
> What is the intention behind this option? is it still accurate and a MUST?
> Could someone explain in detail why this has to be set.
>
> thanks
>
> best wishes
> lovetox
>
> ___
> 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-0223: Clarification

[Holger Weiß]

* Sergey Dobrov  [2016-10-22 09:33]:
> On 21/10/2016 23:47, forenjunkie wrote:
> > Especially #publish-options is missing from a lot of servers.
> > Missing as in the server is capable of it but does deliberately not
> > publish that feature.
>
> As I understand, this is just an example and they decided to use the
> #publish-options just to make the conversation between the server and the
> client more concise. There should be no problem to perform the node
> configuration in a separate query and still comply with the XEP.

XEP-0223 says:

| In order for the client to reliably persist private information, the
| virtual pubsub service must also support the "publish-options" feature
| defined in XEP-0060. [...]
|
| Before an account owner attempts to complete any of the use cases
| defined herein, its client SHOULD verify that the account owner's
| server supports both PEP and the "publish-options" feature. [...]
|
| The server MUST return an identity of "pubsub/pep" and include the
| "publish-options" feauture [...].

Given that XEP-0060 doesn't clearly specify how the server should handle
pubsub#persist_items and pubsub#access_model when submitted as
publish-options, I think XEP-0223 should not refer to publish-options
and rather just mandate an appropriate node configuration.

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

Re: [Standards] XEP-0223: Clarification

[Evgeny Khramtsov]

Fri, 21 Oct 2016 23:47:25 +0200
forenjunkie  wrote:

> Hi,
> Maybe its just my impression but it seems there is not much Server 
> support for this XEP
> 
> Especially #publish-options is missing from a lot of servers.
> Missing as in the server is capable of it but does deliberately not 
> publish that feature.
> 
> What is the intention behind this option? is it still accurate and a
> MUST? Could someone explain in detail why this has to be set.

I would also like to add that xdata spec for pubsub#publish-options [1]
is incorrect, as it should be a copy of pubsub#node_config spec [2]
We have only 'pubsub#access_model' defined in the spec, but, for
example, in XEP-0223 [3] we have 'pubsub#persist_items' usage in
Example 1 [4]

[1] http://xmpp.org/extensions/xep-0060.html#registrar-formtypes-publish
[2] http://xmpp.org/extensions/xep-0060.html#registrar-formtypes-config
[3] http://xmpp.org/extensions/xep-0223.html
[4] http://xmpp.org/extensions/xep-0223.html#howitworks
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0223: Clarification

[Sergey Dobrov]

Hi,

On 21/10/2016 23:47, forenjunkie wrote:

Hi,
Maybe its just my impression but it seems there is not much Server
support for this XEP

Especially #publish-options is missing from a lot of servers.
Missing as in the server is capable of it but does deliberately not
publish that feature.
As I understand, this is just an example and they decided to use the 
#publish-options just to make the conversation between the server and 
the client more concise. There should be no problem to perform the node 
configuration in a separate query and still comply with the XEP.


Thanks.



What is the intention behind this option? is it still accurate and a MUST?
Could someone explain in detail why this has to be set.

thanks

best wishes
lovetox


___
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
___