Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)

[Evgeny]

On Sat, Apr 6, 2019 at 5:59 PM, Jonas Schäfer  
wrote:
I agree with Florian fully. This is rather non-idiomatic to implement 
on the
client side, due to how XMPP works otherwise. The flow suggested by 
Florian is

more idiomatic and implementable with less brain-hurt.

I don’t see any advantage (only disadvantages) on the client side 
with the
message based flow (also, the horrors of carbons and archives), and 
I’m not

sure which advantages there would be for servers.


No problem, I will re-design the flow, this is absolutely not a subject 
for debates for me.


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

Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)

[Jonas Schäfer]

On Donnerstag, 4. April 2019 12:52:15 CEST Florian Schmaus wrote:
> On 02.04.19 10:07, Evgeny wrote:
> > On Mon, Apr 1, 2019 at 9:40 PM, Florian Schmaus  wrote:
> >> I am a little bit worried that this will take a few detours to implement
> >> cleanly and elegant in clients and client libraries. Especially since
> >> this pattern never occurred before.
> >> 
> >> Instead I suggest the following control flow, which should be straight
> > 
> >> forward to implement with the facilities libraries currently provide:
> > Hi, Florian, thanks for your feedback.
> > Interestingly, in my very rough version I had exactly this scheme, and I
> > found no real advantage.
> 
> Is it possible that you looked at it with your XMPP server developer
> googles on? :)
> 
> > Instead, I made it possible to just resend the
> > request (with the same CertificateRequest structure) if a client
> > believes the challenge is resolved.
> 
> So XEP-0417 specifies that upon solving the challenge I have to resend
> the IQ request? I could not tell that this is the case, as you can see
> from how I modelled the anticipated current protocol flow in my previous
> message and below. Nevertheless I still would favour my suggested
> protocol flow.
> 
> > What "detours" do you see possible
> > from a client developer perspective?
> 
> Assume that most client libraries provide a facility to send a IQ
> request, gather the response, or bail out on a timeout, and ensures that
> no resources leak. The following should be considered pseudocode but
> roughly reassembles Smack's API and thus may remember you of Java.

I agree with Florian fully. This is rather non-idiomatic to implement on the 
client side, due to how XMPP works otherwise. The flow suggested by Florian is 
more idiomatic and implementable with less brain-hurt.

I don’t see any advantage (only disadvantages) on the client side with the 
message based flow (also, the horrors of carbons and archives), and I’m not 
sure which advantages there would be for servers.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2019-02-27

[Timothée Jaussoin]

Le 06/04/2019 à 10:19, Jonas Schäfer a écrit :

On Mittwoch, 13. März 2019 16:57:07 CEST Kevin Smith wrote:

On 2 Mar 2019, at 18:56, Tedd Sterr  wrote:

3a) PR #758 - XEP-0060: Expose pubsub#access_model and
pubsub#publish_model - https://github.com/xsf/xeps/pull/758
 Jonas assumes this is still
optional, so that existing services aren't suddenly non-compliant; Link
confirms.

As far as I can tell, this is inside an if you do this (OPTIONAL) you SHOULD
include all the fields, so it’s not clear to me that this is true.

I think I should -1 on that basis, but hoping that someone tells me I’ve
misunderstood.

I am going over the open PRs and came across this.

So my understanding is that node configuration is dynamic and the XEP lists a
lot of fields which may or may not be supported. My understanding is that a
client can not rely on all of the fields to be there anyways:


If metadata is provided, it SHOULD include values for all configured options
as well as "automatic" information such as the node creation date, a list of
publishers, and the like.

So I read it this way:

- A client cannot rely on a server providing all configured options anyways.
- pubsub#access_model and pubsub#publish_model exist and are configuration
options.
- A server SHOULD include configuration options in that form. The current
example do not show the two existing options. So one could read this PR as
making the example more compliant.

I don’t think this is a breaking change either way; services may support or
not-support arbitrary node configuration options anyways, and clients *have*
to deal with stuff missing in any form in pubsub anyways.

Please correct me if I’m wrong.

kind regards,
Jonas

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


Thanks for the review Jonas,

This is exactly how I saw that change in the XEP yes :)

Regards,

Timothée Jaussoin

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

Re: [Standards] Proposal: Re-Design of the XEP HTML Pages

[Jonas Schäfer]

On Samstag, 6. April 2019 12:07:36 CEST Evgeny wrote:
> On Sat, Apr 6, 2019 at 12:59 PM, Jonas Schäfer 
> 
> wrote:
> > I integrated more feedback and after lots of folks shouting "SHIP IT"
> > at me
> > and it haunting me in my dreams (not really), I decided to give it a
> > shot.
> 
> Is it possible to render full author's name in the version history?

Unfortunately not, because we do not have that information in the version 
history.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposal: Re-Design of the XEP HTML Pages

[Evgeny]

On Sat, Apr 6, 2019 at 12:59 PM, Jonas Schäfer  
wrote:
I integrated more feedback and after lots of folks shouting "SHIP IT" 
at me
and it haunting me in my dreams (not really), I decided to give it a 
shot.


Is it possible to render full author's name in the version history?

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

Re: [Standards] Proposal: Re-Design of the XEP HTML Pages

[Jonas Schäfer]

Hi folks,

I integrated more feedback and after lots of folks shouting "SHIP IT" at me 
and it haunting me in my dreams (not really), I decided to give it a shot.

The new CSS and XSL is live on xmpp.org as we speak. Make sure to flush your 
browser caches if things look odd (unfortunately).

Mind that this is not meant to be set in stone, and I’m still open for more 
feedback in any direction! :)

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2019-02-27

[Jonas Schäfer]

On Mittwoch, 13. März 2019 16:57:07 CEST Kevin Smith wrote:
> On 2 Mar 2019, at 18:56, Tedd Sterr  wrote:
> > 3a) PR #758 - XEP-0060: Expose pubsub#access_model and
> > pubsub#publish_model - https://github.com/xsf/xeps/pull/758
> >  Jonas assumes this is still
> > optional, so that existing services aren't suddenly non-compliant; Link
> > confirms.
> As far as I can tell, this is inside an if you do this (OPTIONAL) you SHOULD
> include all the fields, so it’s not clear to me that this is true.
> 
> I think I should -1 on that basis, but hoping that someone tells me I’ve
> misunderstood.

I am going over the open PRs and came across this.

So my understanding is that node configuration is dynamic and the XEP lists a 
lot of fields which may or may not be supported. My understanding is that a 
client can not rely on all of the fields to be there anyways:

> If metadata is provided, it SHOULD include values for all configured options 
> as well as "automatic" information such as the node creation date, a list of 
> publishers, and the like.

So I read it this way:

- A client cannot rely on a server providing all configured options anyways.
- pubsub#access_model and pubsub#publish_model exist and are configuration 
options.
- A server SHOULD include configuration options in that form. The current 
example do not show the two existing options. So one could read this PR as 
making the example more compliant.

I don’t think this is a breaking change either way; services may support or 
not-support arbitrary node configuration options anyways, and clients *have* 
to deal with stuff missing in any form in pubsub anyways.

Please correct me if I’m wrong.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___