Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS

[Dave Cridland]

Old Thread Alert!!

On Thu, 13 Feb 2020 at 04:33, Travis Burtrum  wrote:

> In practice, it doesn't matter, the server administrator can't actually
> count on anyone accessing any of the SRV records in any specific order
> because any network could have any types of blocks/constraints on it.
> Therefore pending further comments here I'll submit a PR to propose
> changing:
>
> > Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record
> with regard to connection order as specified by RFC 2782 [3], in that
> all priorities and weights are mixed. This enables the server operator
> to decide if they would rather clients connect with STARTTLS or direct
> TLS. However, clients MAY choose to prefer one type of connection over
> the other.
>
> to something like this instead:
>
> > Both 'xmpp-' and 'xmpps-' records MAY be treated as the same record
> with regard to connection order as specified by RFC 2782 [3], in that
> all priorities and weights are mixed. Otherwise clients MAY choose to
> prefer one type of connection over the other.
>

I propose:

Both 'xmpp' and 'xmpps' records MAY be treated as the same record with
regard to connection order as specified by RFC 2782 [3], in that all
priorities and weights are mixed. However, initiating entities MAY choose
to prefer Direct TLS, including by exhausting all 'xmpps' records prior to
attempting any 'xmpp' records.

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

[Standards] Council Minutes 2021-09-01

[Jonas Schäfer]

https://logs.xmpp.org/council/2021-09-01#2021-09-01-066a7bbc68369c8e

1) Roll Call

Present: Jonas, Zash, Georg, Dave

2) Agenda Bashing

None.

3) Editor’s Update

Stable is the new Draft.

4) Items for Voting

None.

5) Pending Votes

Dave votes +1 on [1].

6) Date of Next

Everyone (present) in for +1w, except Jonas. Georg steps up to step in as a 
Chair.

7) AOB

7a) Membership Applications

Georg reminds the Council that the new round of membership applications is due 
and at least two members should reapply in order to not drop off Council as 
per the Bylaws:

> All the individuals elected to participate on the XMPP Council must be 
> Members of the Corporation.
> 
> If a Council member resigns his or her membership in the Corporation, is 
> removed from membership in the Corporation, or is terminated from membership 
> in the Corporation, he or she shall thereby relinquish all rights and 
> responsibilities as a member of the Council.

7b) End of Council Term incoming

Georg mentions that we should look at what we should be LCing to achieve a 
smooth transition.

He specifically points at CS-2022, XEP-0280 and XEP-0313.

For CS-2022, Jonas is contacting the author.

For XEP-0280, Georg is very sorry about not having put in the work yet to make 
it ready for advancement.

For XEP-0313, a discussion starts.

Dave and Jonas think that not being able to advance this document is really 
silly. Like '280, it has wide deployment is de-facto Stable anyway.

Georg have liked to do things right in the last call, with two pages of 
feedback.

Jonas points out that any changes to '313 are either achievable in Stable or 
are too breaking for Stable. If they are too breaking for Stable, they would 
not be realistically deployed any time soon anyway, because of the widespread 
use and the disruptiveness of changing MAM.

In addition, it is pointed out that IM-NG might be a better way to spend 
energy instead of microoptimizing MAM and Carbons, which seem to work "well 
enough" in practice.

8) Ite Meeting Est

Thanks everyone.


   [1]: https://mail.jabber.org/pipermail/standards/2021-August/038508.html
   [2]: https://github.com/xsf/xeps/pull/1100/files


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
___

[Standards] XSF membership application period Q4 2021

[Alexander Gnauck]

I have setup the membership application Wiki page for the application 
period Q4 2021


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:

https://wiki.xmpp.org/web/Membership_Applications_Q4_2021

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

Apply now!!!

Thanks,
Alex

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

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

[JC Brand]

On 31.08.21 17:23, Jonas Schäfer wrote:

Libraries which currently represent body as a
(mappnig of language tags to) string(s) would now need extra magic in order to
be able to set ID attributes on those. This feels like a quite major change,
and not just to References, but to literally everything else.


Do you know of any such libraries in existence?

XEPs are expected to maintain backwards compatibility (i.e. not break 
old clients), but forwards compatibility (providing their features to 
old clients) is not required.
My proposal won't break such a library, it just won't have my proposed 
disambiguation feature for XEP-0372.


---

I did some digging, and XEP-0274 "Design Considerations for Digital 
Signatures" uses the same mechanism that I'm proposing.

See here: https://xmpp.org/extensions/xep-0274.html#manifest

An "id" attribute is put on the   and the  element 
has a URI attribute that points to it.


XEP-0290 does something similar. A prefixed namespace attribute is put 
on the  (e.g. ) and 
then used in the .


So I'm not the first person to think of using references in this way.

Funnily enough, in both cases they're using the URI attribute, which to 
my understanding of XEP-0372 is wrong. The "anchor" is used to identify 
the referenced element, and the "URI" is what the referenced text is 
pointing to.


- JC


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

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

[JC Brand]

On 01.09.21 10:23, Sergey Ilinykh wrote:
I mean to use both *anchor* and *xml:lang* attributes to not write a 
complicated element query parser if one is not provided by the used libs.


What would you then put in the "anchor" attribute?

If you say just the name of the referenced element (e.g. "body" or 
"subject"), well then there is still a problem with for example XEP-0316 
MUC PEP messages where you can have multiple  elements that you'd 
like to have mentions for. In such a case, the element name and 
"xml:lang" attribute aren't sufficient to know which  element is 
being referred to.


If you say an id selector (e.g. #abc123), then we're back to my original 
proposal, which works for all the use-cases brought up so far, but which 
requires an "id" attribute on the referenced element.


- JC

ср, 1 сент. 2021 г. в 11:10, JC Brand >:




On 01.09.21 10:06, Sergey Ilinykh wrote:

why not just

```

```
?


Because that doesn't distinguish between elements with different
names.
Is that reference based on the  or  tag? Or
perhaps a  tag?

- JC


ср, 1 сент. 2021 г. в 10:59, JC Brand mailto:li...@opkode.com>>:

Hi Jonas

On 31.08.21 17:23, Jonas Schäfer wrote:

Hi JC,

This has somehow slipped past me.


Thanks for taking the time to respond.


On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:

So, if you have a stanza with for example, both "subject" and "body"
tags, we can have references for both, and use the "anchor" attribute as
follows (I hope this comes out formatted properly once sent):

mailto:sch...@springfield.city>>
  Attention Bart Simpson
  Please hand in your homework before the end of the
day
  


What about messages with multiple  elements disambiguated by 
xml:lang?
Could some conceivably contain a mention while others don't? Does this 
require
replicating the mention element all over? Same question for .

This is another currently ambiguous and undefined use-case
that I think can be solved with my proposal.
As the XEP currently stands, there's no documented way to
distinguish between multiple  (or ) elements.

Going with my proposal, the solution would be to have a
separate  element for each .
The mention parameters ("begin", "end") will be different for
each  since the mentioned text usually won't be in the
exact same place for the different translations.

The "id" attribute can have any value, it doesn't have to be
"body" or "subject", those were just examples.


Besides that, I don't think that adding an attribute to an element in 
this way
is really acceptable.

I would prefer an approach which identifies the XML element without 
having to
modify the XML being referenced.

The only mechanism that doesn't require modifying the
referenced elements that I can think of is XPath.

My example then becomes:

mailto:sch...@springfield.city>>
  Attention Bart Simpson
  Aandag Bart Simpson
  Please hand in your homework before the end of the 
day
  Handig asseblief jou huiswerk in voor die einde van 
die dag
  
  
  

Regards
JC



Libraries which currently represent body as a
(mappnig of language tags to) string(s) would now need extra magic in 
order to
be able to set ID attributes on those. This feels like a quite major 
change,
and not just to References, but to literally everything else.

kind regards,
Jonas

[1]:https://www.w3.org/TR/REC-xml/#id  



___
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-0372 references pointing to different elements in same stanza

[Sergey Ilinykh]

I mean to use both *anchor* and *xml:lang* attributes to not write a
complicated element query parser if one is not provided by the used libs.

Best Regards,
Sergey


ср, 1 сент. 2021 г. в 11:10, JC Brand :

>
>
> On 01.09.21 10:06, Sergey Ilinykh wrote:
>
> why not just
>
> ```
>
> 
> ```
> ?
>
>
> Because that doesn't distinguish between elements with different names.
> Is that reference based on the  or  tag? Or perhaps a
>  tag?
>
> - JC
>
> ср, 1 сент. 2021 г. в 10:59, JC Brand :
>
>> Hi Jonas
>>
>> On 31.08.21 17:23, Jonas Schäfer wrote:
>>
>> Hi JC,
>>
>> This has somehow slipped past me.
>>
>>
>> Thanks for taking the time to respond.
>>
>> On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:
>>
>> So, if you have a stanza with for example, both "subject" and "body"
>> tags, we can have references for both, and use the "anchor" attribute as
>> follows (I hope this comes out formatted properly once sent):
>>
>> > >
>>  Attention Bart Simpson
>>  Please hand in your homework before the end of the
>> day
>>  
>> 
>>
>> What about messages with multiple  elements disambiguated by xml:lang?
>> Could some conceivably contain a mention while others don't? Does this 
>> require
>> replicating the mention element all over? Same question for .
>>
>> This is another currently ambiguous and undefined use-case that I think
>> can be solved with my proposal.
>> As the XEP currently stands, there's no documented way to distinguish
>> between multiple  (or ) elements.
>>
>> Going with my proposal, the solution would be to have a separate
>>  element for each .
>> The mention parameters ("begin", "end") will be different for each
>>  since the mentioned text usually won't be in the exact same place
>> for the different translations.
>>
>> The "id" attribute can have any value, it doesn't have to be "body" or
>> "subject", those were just examples.
>>
>> Besides that, I don't think that adding an attribute to an element in this 
>> way
>> is really acceptable.
>>
>> I would prefer an approach which identifies the XML element without having to
>> modify the XML being referenced.
>>
>> The only mechanism that doesn't require modifying the referenced elements
>> that I can think of is XPath.
>>
>> My example then becomes:
>>
>> > >
>>  Attention Bart Simpson
>>  Aandag Bart Simpson
>>  Please hand in your homework before the end of the 
>> day
>>  Handig asseblief jou huiswerk in voor die einde van 
>> die dag
>>  > type="mention"/>
>>  > type="mention"/>
>>  
>>
>> Regards
>> JC
>>
>>
>> Libraries which currently represent body as a
>> (mappnig of language tags to) string(s) would now need extra magic in order 
>> to
>> be able to set ID attributes on those. This feels like a quite major change,
>> and not just to References, but to literally everything else.
>>
>> kind regards,
>> Jonas
>>
>>[1]: https://www.w3.org/TR/REC-xml/#id
>>
>>
>> ___
>> 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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0372 references pointing to different elements in same stanza

[JC Brand]

On 01.09.21 10:06, Sergey Ilinykh wrote:

why not just

```

```
?


Because that doesn't distinguish between elements with different names.
Is that reference based on the  or  tag? Or perhaps a 
 tag?


- JC

ср, 1 сент. 2021 г. в 10:59, JC Brand >:


Hi Jonas

On 31.08.21 17:23, Jonas Schäfer wrote:

Hi JC,

This has somehow slipped past me.


Thanks for taking the time to respond.


On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:

So, if you have a stanza with for example, both "subject" and "body"
tags, we can have references for both, and use the "anchor" attribute as
follows (I hope this comes out formatted properly once sent):

mailto:sch...@springfield.city>>
  Attention Bart Simpson
  Please hand in your homework before the end of the
day
  


What about messages with multiple  elements disambiguated by 
xml:lang?
Could some conceivably contain a mention while others don't? Does this 
require
replicating the mention element all over? Same question for .

This is another currently ambiguous and undefined use-case that I
think can be solved with my proposal.
As the XEP currently stands, there's no documented way to
distinguish between multiple  (or ) elements.

Going with my proposal, the solution would be to have a separate
 element for each .
The mention parameters ("begin", "end") will be different for each
 since the mentioned text usually won't be in the exact
same place for the different translations.

The "id" attribute can have any value, it doesn't have to be
"body" or "subject", those were just examples.


Besides that, I don't think that adding an attribute to an element in this 
way
is really acceptable.

I would prefer an approach which identifies the XML element without having 
to
modify the XML being referenced.

The only mechanism that doesn't require modifying the referenced
elements that I can think of is XPath.

My example then becomes:

mailto:sch...@springfield.city>>
  Attention Bart Simpson
  Aandag Bart Simpson
  Please hand in your homework before the end of the 
day
  Handig asseblief jou huiswerk in voor die einde van die 
dag
  
  
  

Regards
JC



Libraries which currently represent body as a
(mappnig of language tags to) string(s) would now need extra magic in order 
to
be able to set ID attributes on those. This feels like a quite major change,
and not just to References, but to literally everything else.

kind regards,
Jonas

[1]:https://www.w3.org/TR/REC-xml/#id  



___
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-0372 references pointing to different elements in same stanza

[Sergey Ilinykh]

why not just

```


```
?


Best Regards,
Sergey


ср, 1 сент. 2021 г. в 10:59, JC Brand :

> Hi Jonas
>
> On 31.08.21 17:23, Jonas Schäfer wrote:
>
> Hi JC,
>
> This has somehow slipped past me.
>
>
> Thanks for taking the time to respond.
>
> On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:
>
> So, if you have a stanza with for example, both "subject" and "body"
> tags, we can have references for both, and use the "anchor" attribute as
> follows (I hope this comes out formatted properly once sent):
>
>  >
>  Attention Bart Simpson
>  Please hand in your homework before the end of the
> day
>  
> 
>
> What about messages with multiple  elements disambiguated by xml:lang?
> Could some conceivably contain a mention while others don't? Does this require
> replicating the mention element all over? Same question for .
>
> This is another currently ambiguous and undefined use-case that I think
> can be solved with my proposal.
> As the XEP currently stands, there's no documented way to distinguish
> between multiple  (or ) elements.
>
> Going with my proposal, the solution would be to have a separate
>  element for each .
> The mention parameters ("begin", "end") will be different for each 
> since the mentioned text usually won't be in the exact same place for the
> different translations.
>
> The "id" attribute can have any value, it doesn't have to be "body" or
> "subject", those were just examples.
>
> Besides that, I don't think that adding an attribute to an element in this way
> is really acceptable.
>
> I would prefer an approach which identifies the XML element without having to
> modify the XML being referenced.
>
> The only mechanism that doesn't require modifying the referenced elements
> that I can think of is XPath.
>
> My example then becomes:
>
>  >
>  Attention Bart Simpson
>  Aandag Bart Simpson
>  Please hand in your homework before the end of the 
> day
>  Handig asseblief jou huiswerk in voor die einde van 
> die dag
>   type="mention"/>
>   type="mention"/>
>  
>
> Regards
> JC
>
>
> Libraries which currently represent body as a
> (mappnig of language tags to) string(s) would now need extra magic in order to
> be able to set ID attributes on those. This feels like a quite major change,
> and not just to References, but to literally everything else.
>
> kind regards,
> Jonas
>
>[1]: https://www.w3.org/TR/REC-xml/#id
>
>
> ___
> 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-0372 references pointing to different elements in same stanza

[JC Brand]

Hi Jonas

On 31.08.21 17:23, Jonas Schäfer wrote:

Hi JC,

This has somehow slipped past me.


Thanks for taking the time to respond.


On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:

So, if you have a stanza with for example, both "subject" and "body"
tags, we can have references for both, and use the "anchor" attribute as
follows (I hope this comes out formatted properly once sent):


  Attention Bart Simpson
  Please hand in your homework before the end of the
day
  


What about messages with multiple  elements disambiguated by xml:lang?
Could some conceivably contain a mention while others don't? Does this require
replicating the mention element all over? Same question for .
This is another currently ambiguous and undefined use-case that I think 
can be solved with my proposal.
As the XEP currently stands, there's no documented way to distinguish 
between multiple  (or ) elements.


Going with my proposal, the solution would be to have a separate 
 element for each .
The mention parameters ("begin", "end") will be different for each 
 since the mentioned text usually won't be in the exact same 
place for the different translations.


The "id" attribute can have any value, it doesn't have to be "body" or 
"subject", those were just examples.



Besides that, I don't think that adding an attribute to an element in this way
is really acceptable.

I would prefer an approach which identifies the XML element without having to
modify the XML being referenced.
The only mechanism that doesn't require modifying the referenced 
elements that I can think of is XPath.


My example then becomes:


 Attention Bart Simpson
 Aandag Bart Simpson
 Please hand in your homework before the end of the 
day
 Handig asseblief jou huiswerk in voor die einde van die 
dag
 
 
 

Regards
JC



Libraries which currently represent body as a
(mappnig of language tags to) string(s) would now need extra magic in order to
be able to set ID attributes on those. This feels like a quite major change,
and not just to References, but to literally everything else.

kind regards,
Jonas

[1]: https://www.w3.org/TR/REC-xml/#id


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