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

[JC Brand]

On 09.09.21 19:22, Sam Whited wrote:

Seems like we might as well use the element name since that has to be
unique; one less unique ID to store.
Element names are not unique. For example, you can have multiple  
elements in a PEP message.


This is why my request is for the "anchor" attribute of the  
to use a URI fragment to point to the "id" attribute of the element 
being referenced.



Also if you have a schema, structs,
etc. in your language of choice you now don't have to go update them for
every possible element to add an id attribute, there aren't conflicts
with anything that already has an id attribute that we inevitably will
want to reference in the future, etc.

That being said, my concern is that some libraries would treat
 as "{}subject" and some would treat it as
"{jabber:client}subject".

—Sam

On Thu, Sep 9, 2021, at 13:15, Kevin Smith wrote:

It’s not the element name, it’s just (possibly unfortunately) the same
in that example. It’s the 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]

On 09.09.21 19:15, Kevin Smith wrote:

On 9 Sep 2021, at 18:06, Florian Schmaus  wrote:

On 13/08/2021 14.00, JC Brand wrote:> 

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


Why is there a number sign ('#') before the element name? What if there is 
another first-level stanza child element with a local name 'subject' but a 
different namespace?

It’s not the element name, it’s just (possibly unfortunately) the same in that 
example. It’s the id.


Yes, it's not the element name, it's a URI fragment pointing to the 
element id.


Due to my poor choice of ID, people got confused. So here's a new example:


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



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

Re: [Standards] Stable is the new Draft

[Peter Saint-Andre]

On 9/8/21 6:19 AM, Dave Cridland wrote:
> 
> 
> On Tue, 7 Sept 2021 at 16:44, Peter Saint-Andre  > wrote:
> 
> On 8/31/21 9:41 AM, Jonas Schäfer wrote:
> 
> > The term "Draft" for our non-Final but also non-Experimental
> standards has
> > been adopted from our "mother" organization, the Internet
> Engineering Task
> > Force. The IETF has since abandoned that term.
> 
> In fact, the IETF moved from a three-stage track to a two-stage track:
> 
> 
> As many of us noted in the discussion leading up to that, the IETF moved
> from a three-stage to a four-stage by increasingly formalizing the
> Internet-Draft stage and raising the bar for Proposed Standard, and then
> RFC 6410 executed a "Left Shift" to remove the (now largely redundant)
> Draft stage.
> 
> The IETF still has a three stage track, it's just that the first stage
> is Internet-Drafts, which amounts to our Experimental.
> 
> A lot of this shift, looking back on it, was driven by the lack of
> in-situ updates to documents once they'd hit RFC status, which doesn't
> affect us.

That's all true.

> It's also why I have resisted adding pre-XEP stages...

And let's keep resisting. :-)

Peter

___
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

[Sam Whited]

Seems like we might as well use the element name since that has to be
unique; one less unique ID to store. Also if you have a schema, structs,
etc. in your language of choice you now don't have to go update them for
every possible element to add an id attribute, there aren't conflicts
with anything that already has an id attribute that we inevitably will
want to reference in the future, etc.

That being said, my concern is that some libraries would treat
 as "{}subject" and some would treat it as
"{jabber:client}subject".

—Sam

On Thu, Sep 9, 2021, at 13:15, Kevin Smith wrote:
> It’s not the element name, it’s just (possibly unfortunately) the same
> in that example. It’s the id.
___
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

[Kevin Smith]

> On 9 Sep 2021, at 18:06, Florian Schmaus  wrote:
> 
> On 13/08/2021 14.00, JC Brand wrote:>  from="sch...@springfield.city">
>> Attention Bart Simpson
>> Please hand in your homework before the end of the 
>> day
>> 
>> 
> 
> Why is there a number sign ('#') before the element name? What if there is 
> another first-level stanza child element with a local name 'subject' but a 
> different namespace?

It’s not the element name, it’s just (possibly unfortunately) the same in that 
example. It’s the id. 

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

[Florian Schmaus]

On 13/08/2021 14.00, JC Brand wrote:> from="sch...@springfield.city">

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

     



Why is there a number sign ('#') before the element name? What if there 
is another first-level stanza child element with a local name 'subject' 
but a different namespace?


I am happy to ignore the existence of xml:lang for now, but I think the 
'anchor' attribute value should be specified to be either in Clark 
notation, or, if not, reference first-level stanza child elements by 
their localname with the same namespace as the stanza. So your example 
becomes



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




and, in case of a theoretical  element.


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




- Florian



OpenPGP_signature
Description: OpenPGP digital signature
___
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

[Kevin Smith]

On 13 Aug 2021, at 13:00, JC Brand  wrote:
> 
> Hi everyone
> 
> In XEP-0372, when references are used for "mentions", there is an implicit 
> assumption that the referenced text is in the  tag.
> 
> There are however other elements where mentions could also occur, such as 
> ,  and , and some stanzas could have multiple possible 
> elements whose text might be referenced.
> 
> XEP-0372 provides an "anchor" attribute for the  tag, which can be 
> used to refer to other addressable entities, to handle the case where the 
> reference points to something in another stanza.
> 
> I think this "anchor" attribute can also be used to disambiguate the 
> references in a stanza that has multiple text-containing elements. In this 
> case, instead of letting the anchor point to an XMPP URI, it would only point 
> to a fragment, meaning that the fragment is inside the same stanza.
> 
> In HTML the fragment of a URI points to an element with the same id attribute 
> value as the fragment itself, but apparently this isn't a general requirement 
> for URIs. In this case, for simplicity, I would however stick to that 
> convention.
> 
> 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
> 
> 
> 
> I think this is an elegant solution that uses the existing mechanics, and the 
> only further requirement would be to clarify in the XEP that the anchor 
> attribute can be used in this way.
> 
> I'd be happy to hear your thoughts and feedback.

This doesn’t sound terrible to me. Anything we do here will be a bit icky, but 
at least this is trivial to implement and doesn’t require pulling in an xpath 
library, and isn’t trying to recreate xpath with a different syntax (which was 
what I first thought it would lead to).

/K

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

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Kevin Smith]

To summarise what I’ve said before:

MUC in MAM kinda sucks, but groupchat doesn’t (necessarily) mean MUC.
Sometimes people want groupchat messages in their archive because they want 
their archive to represent all those messages they received on any client, 
either for online searching, or offline sync, and MAM is the only mechanism we 
have for this.
If we were to disallow groupchat in MAM completely, it would make existing 
deployed workflows unavailable.
There are countless pitfalls to having MUC (rather than groupchat) in MAM, but 
prohibiting it just isn’t much of an option. I don’t much like where we are 
more than anyone else, but it *is* where we are, and I don’t think anyone has 
the time machine yet to go back and fix MUC preemptively.

After discussion with Georg yesterday, I’ve submitted a new version of MAM that 
uses Dave’s suggested approach.

/K

> On 8 Sep 2021, at 09:00, Georg Lukas  wrote:
> 
> * Kevin Smith  [2021-09-07 18:41]:
>> At the risk of repeating myself, I think that storing groupchat messages in 
>> the user archives is helpful, and people do this in the wild.
> 
> Right, I remember hearing that before, and IIRC the reason for that was
> to allow for server-side message search?
> 
> Now I have multiple practical questions regarding how this is supposed
> to work.
> 
> First, how and when are groupchat messages from MAM delivered to a
> client? I can understand that it will mostly work well when querying for
> the room JID. But what happens on a query that's only filtered by
> `start` or `after-id`? Will the server intermix all groupchat messages
> with all direct messages? Will it only send groupchats from the rooms
> that some client of that user is currently joined? Only the rooms that
> the querying client is joined? ...was joined in the past? Groupchats
> have typically a much higher singal-to-noise ratio and could
> significantly delay the loading of the really important messages here ;)
> Should there be a difference between "channels" (public semi-anon rooms)
> and "group chats" (closed non-anon rooms)?
> 
> 
> Second, how does the MAM service ensure that the MUC history is complete
> and does not contain holes, e.g. because all of the user's client left
> the room at a certain time, or due to s2s outages? Or is there no such
> guarantee, rendering the archive less than useful? Will the personal
> archive re-populate MUC history when a client does a MAM query on the
> MUC archive? Should the personal archive do MAM requests on its own?
> 
> 
> Third, how is deduplication supposed to work? Will the user's archive
> add its own  and only allow querying by that? How is a client
> going to consolidate MUC messages based on their MUC-assigned stanza-ids
> with ones from the personal archive - or is the client supposed to
> ignore the MUC-assigned IDs?
> 
> 
> Fourth, a personal MAM archive MAY exclude groupchat messages if these
> are already archived on the MUC JID. There is no explicit signalling for
> this, so I assume the most straight-forward implementation would be to
> check all passing messages for the presence of a stanza-id field added
> by the MUC JID, and to prevent storage of these. Let's ignore that a MUC
> service or a room might change its archival preferences over the time,
> we are still lacking a mechanism for the client to decide which JID to
> query to obtain a MUC history. Should it first query the personal
> archive and only fall back to the MUC archive if it receives an error?
> An empty result set?
> 
> 
>> So if there *was* somehow agreement for forbidding it, it would need a
>> namespace bump, because it used to be allowed (and, indeed,
>> recommended).
> 
> Well, given that a server MAY exclude groupchat messages if history is
> accessible through other means, and given that 0045 includes a mechanism
> for fetching history, I would say that a namespace bump is not needed ;-)
> 
> 
> Georg
> ___
> 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
___