Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Jonas Wielicki]

On Sonntag, 4. März 2018 19:42:39 CET Peter Saint-Andre wrote:
> On 3/4/18 10:54 AM, Jonas Wielicki wrote:
> > On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote:
> >> If we want to specify this, I would recommend the UsernameCaseMapped
> >> profile defined in RFC 8265.
> >> 
> >> However, there's a twist: if a node ID can be a full JID, then do we
> >> want to apply the normal rules of RFC 7622 to all the JID parts, instead
> >> of one uniform profile such as UsernameCaseMapped to the entire node ID?
> >> For instance, the resourcepart of a JID is allowed to contain a much
> >> wider range of Unicode characters than is allowed by the
> >> UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
> >> for the localpart).
> >> 
> >> Given that a node ID can be used for authorization decisions, I think
> >> it's better to be conservative in what we accept (specifically, not
> >> allow the wider range of characters in a resourcepart because
> >> developers, and attackers, could get too "creative").
> > 
> > I would argue that adding those restrictions / any kind of string prepping
> > to XEP-0060 or XEP-0030 nodes is (a) too late and (b) ambiguous at least,
> > as you mentioned (depending on the data).
> 
> I would argue that not specifying normalization rules is a security hole
> (e.g., allowing an attacker to gain unauthorized access to a node). Just
> because we should've done this years ago doesn't mean we can fix it now.

Hm, okay, I don’t seem to understand the attack vector. Could you spell it out 
more clearly to me?

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] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Florian Schmaus]

On 04.03.2018 17:02, Peter Saint-Andre wrote:
> On 3/4/18 1:27 AM, Florian Schmaus wrote:
>> On 04.03.2018 02:30, Peter Saint-Andre wrote:
 On Mar 3, 2018, at 2:36 PM, Timothée Jaussoin  wrote:
 Thanks for the answers. I'm fine for the 3071 limitation, so we can set it 
 both for the Pubsub nodes id and Pubsub items it?
 If yes I'm ok to do a PR on the 0060 to specify that. I'm also wondering 
 if there is a specific way of declaring such string
 limitations, are you aware of any other XEPs that specify such things?
>>>
>>> As mentioned, I think this belongs in XEP-0030 but I suppose it can be 
>>> defined in XEP-0060.
>>
>> Could you elaborate why you think that it belongs in xep30? Are xep30
>> item node's related to xep60 nodes? How fit xep60 item IDs into this?
> 
> The concept of a node was originally defined in XEP-0030, and the usage
> in XEP-0060 borrowed from XEP-0030. The former is more fundamental and
> thus I think it would be good to specify this in XEP-0030 (so that
> "node" means the same thing across all protocol extensions). Or we could
> resurrect XEP-0271:
> 
> https://xmpp.org/extensions/xep-0271.html

Whatever we do, there should have a prominent pointer from the affected
XEPs to the place where we specific the limitations on node values.

>> Related: I wonder if we should specify string preparation for xep60 node
>> and item ID strings. Same goes for the strings used by xep30, e.g.
>> 's 'var' attribute value. Is any Unicode string a valid value
>> for those? Or is this already specified somewhere and I just missed it?
> 
> If we want to specify this, I would recommend the UsernameCaseMapped
> profile defined in RFC 8265.
> 
> However, there's a twist: if a node ID can be a full JID, then do we
> want to apply the normal rules of RFC 7622 to all the JID parts, instead
> of one uniform profile such as UsernameCaseMapped to the entire node ID?
> For instance, the resourcepart of a JID is allowed to contain a much
> wider range of Unicode characters than is allowed by the
> UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
> for the localpart).

I believe the following requirements are sensible:
1.) If we specify a profile, then it must be applied to the whole value
2.) Since it is a common use case to put JIDs into node ID values, we
must ensure that distinct (full?) JIDs, do not map not the same node ID.

And if I'm not mistaken, resourceparts are case preserving, as result it
depends on whether or not we deem support for full JIDs in node IDs
worthwhile, which PRECIS profiles we need to consider.

- 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] xep-0313 missing features

[Lazar Otasevic]

See my answer to Mathew, maybe i clarified better. cu

On Sun, Mar 4, 2018 at 9:08 PM, Philipp Hörist  wrote:

>
> 2018-03-04 18:37 GMT+01:00 Lazar Otasevic :
>
>> Phillip,
>>
>> I feel like we dont entirely understand each other. Are you sure you did
>> read and understood my post?
>>
>> Getting array of ids gives you the order because ids should come in the
>> order respective messages are archived, and getting content is an extra
>> step above, unrelated to order. Content should be fetched by giving ANY set
>> of ids, like SQL SELECT...IN
>>
>> Where in my statements you see that I don't treat ids as opaque?
>>
>> Regards
>>
>>
>>
> You wrote that you react to a push notification, meaning you request one
> specific message without first getting a list of ids and checking what you
> are missing and the order.
>
> But i think i get what you want, just like email, request the headers but
> not the content, because you think its inefficient to download messages
> that you potentially already have.
>
>
>
> ___
> 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-0313 missing features

[Lazar Otasevic]

>
>
> > Matthew,
>
> I really don't understand this argument. Doing a MAM query is exactly
> like fetching a list of ids, except that you also get the content as
> well. As I mentioned, I see no case in which you would want the ids
> and not the content. Even if you get the ids, you will fetch the
> content later.
>

yes, MAM query is exactly "like" fetching a list of ids combined with
content, but thats the problem i have from the start :)

getting the ids+content in the same query is a waste in some (many) cases
because local archive can have holes in it when network is bad and lots of
disconnects happen (for example live messages come before sync is completed
and then disconnect happens = next time we receive immediately some live
messages and we have holes)

even when we dont have a hole, we may trigger a page fetch of 10 messages
where infect we need only 2-3, and again we have a waste

in my proposal waste would be only some of the ids discarder, so very
little. good thing is that ids can come immediately in iq response and
client don't need to collect it out of the stream like in MAM now. and more
good thing see below...


If you already have the content, why would the client ever perform a
> query that overlaps with ranges of messages that it already has? Just
> none of this makes any sense to me


see previous - holes


> > I agree "back filling" feels wrong for someone and feels right for
> someone
> > else so its not an argument for technical discussion. Anyhow, direction
> of
> > iteration should be a client choice (server needs to provide both
> directions
> > possible).
>
> By back-filling I was less concerned about the direction and more
> concerned with showing the user a new message in the conversation
> without also showing them the messages before it. That is, showing a
> conversation with "holes" in.
>

any user friendly client should not prevent user to do live communication
while the sync is in progress. and there you gave a hole already.
conclusion: clients should not focus too much on solving something that is
out of their control, and that is holes. BTW viber works from newest
message to oldest ones, i have a video of viber on a bad network to prove
it.


> I totally *do* understand that some clients would like to fill the
> message log backwards dynamically as a user scrolls. Querying
> backwards from a known id is already possible.
>
> yes we elaborated that


> > I thought the goal of XMPP is to make clients less complex and more
> > reliable? Why is adding two (basic) features counted as increasing
> > complexity? I say basic because those features were kind of existent
> back in
> > 2005 in xep-0013. Now we removed those features, why?
>
> Can you explain what your ideal client logic would be? And how it is
> more simple than "the latest message I have has ID X, request all
> messages since X"?
>

yes, i can give you not only ideal logic but also ideal SW design of a
client...

lets say I make client from 3 components: sender, receiver and sync.
goal is to have them decoupled, and the only shared part will be the local
message archive

here is how the archive is filled:
1. sender - fills archive with message content when outgoing message is
confirmed to be sent
2. receiver - fills archive with message content when it receives a live
message
3. sync is the only one that takes care of the order, and also filling the
holes. order is implicitly given by list of ids received from the server,
and holes are easily detected by simple query to archive and then potential
holes filled by an extra request (with collection of ids)

note how everything can work decoupled, no special handling for sync on
connect/disconnect/send/receive, no id tracking, etc... simple and no waste
(except a bit of ids), every component can work with/without every other.

BTW using request with ids for push purposes is just a special case of that
request that we miss.

@Philip maybe you find some answers here?

...
PS one more thing why MAM direction is important to clients is - receipts,
because if client fetches first the message and then the receipt (old to
new) then message is in the wrong state (hint: multidevice or reinstall +
own messages/receipts)



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

Re: [Standards] xep-0313 missing features

[Matthew Wild]

On 4 March 2018 at 17:30, Lazar Otasevic  wrote:
> Matthew,
>
> I may be repeating: every efficient sync algorithm needs iterating trough
> ids and content separately. Of course we may make sync work without
> iterating trough ids, but implementations like that are just terrible, too
> complex, too coupled with the rest of design and not optimal.

I really don't understand this argument. Doing a MAM query is exactly
like fetching a list of ids, except that you also get the content as
well. As I mentioned, I see no case in which you would want the ids
and not the content. Even if you get the ids, you will fetch the
content later.

If you already have the content, why would the client ever perform a
query that overlaps with ranges of messages that it already has? Just
none of this makes any sense to me.

> I agree "back filling" feels wrong for someone and feels right for someone
> else so its not an argument for technical discussion. Anyhow, direction of
> iteration should be a client choice (server needs to provide both directions
> possible).

By back-filling I was less concerned about the direction and more
concerned with showing the user a new message in the conversation
without also showing them the messages before it. That is, showing a
conversation with "holes" in.

I totally *do* understand that some clients would like to fill the
message log backwards dynamically as a user scrolls. Querying
backwards from a known id is already possible.

> I thought the goal of XMPP is to make clients less complex and more
> reliable? Why is adding two (basic) features counted as increasing
> complexity? I say basic because those features were kind of existent back in
> 2005 in xep-0013. Now we removed those features, why?

Can you explain what your ideal client logic would be? And how it is
more simple than "the latest message I have has ID X, request all
messages since X"?

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

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Peter Saint-Andre]

On 3/4/18 10:54 AM, Jonas Wielicki wrote:
> On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote:
>> If we want to specify this, I would recommend the UsernameCaseMapped
>> profile defined in RFC 8265.
>>
>> However, there's a twist: if a node ID can be a full JID, then do we
>> want to apply the normal rules of RFC 7622 to all the JID parts, instead
>> of one uniform profile such as UsernameCaseMapped to the entire node ID?
>> For instance, the resourcepart of a JID is allowed to contain a much
>> wider range of Unicode characters than is allowed by the
>> UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
>> for the localpart).
>>
>> Given that a node ID can be used for authorization decisions, I think
>> it's better to be conservative in what we accept (specifically, not
>> allow the wider range of characters in a resourcepart because
>> developers, and attackers, could get too "creative").
> 
> I would argue that adding those restrictions / any kind of string prepping to 
> XEP-0060 or XEP-0030 nodes is (a) too late and (b) ambiguous at least, as you 
> mentioned (depending on the data).

I would argue that not specifying normalization rules is a security hole
(e.g., allowing an attacker to gain unauthorized access to a node). Just
because we should've done this years ago doesn't mean we can fix it now.

> I’d also argue that nodes aren’t shown or typed into a field by users 
> normally, so I would not worry about that kind of normalization here.

So that only automated attackers can succeed? :-)

> If a specific XEP-0030/XEP-0060-based protocol needs more guarantees, I think 
> those can be defined there.

No, this needs to be done at the lowest level we can manage. Pushing
this off to extensions just means we'll have inconsistent approaches.

Peter




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

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Jonas Wielicki]

On Sonntag, 4. März 2018 17:02:07 CET Peter Saint-Andre wrote:
> If we want to specify this, I would recommend the UsernameCaseMapped
> profile defined in RFC 8265.
> 
> However, there's a twist: if a node ID can be a full JID, then do we
> want to apply the normal rules of RFC 7622 to all the JID parts, instead
> of one uniform profile such as UsernameCaseMapped to the entire node ID?
> For instance, the resourcepart of a JID is allowed to contain a much
> wider range of Unicode characters than is allowed by the
> UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
> for the localpart).
> 
> Given that a node ID can be used for authorization decisions, I think
> it's better to be conservative in what we accept (specifically, not
> allow the wider range of characters in a resourcepart because
> developers, and attackers, could get too "creative").

I would argue that adding those restrictions / any kind of string prepping to 
XEP-0060 or XEP-0030 nodes is (a) too late and (b) ambiguous at least, as you 
mentioned (depending on the data).

I’d also argue that nodes aren’t shown or typed into a field by users 
normally, so I would not worry about that kind of normalization here.

If a specific XEP-0030/XEP-0060-based protocol needs more guarantees, I think 
those can be defined there.

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] Releases

[Jonas Wielicki]

On Sonntag, 4. März 2018 10:29:02 CET Gerion Entrup wrote:
> Hi,
> 
> I'm a user of XMPP and have very mixed experiences with different clients.
> 
> There are clients that do very well and implement a lot of availabe XEPs,
> but other clients only implement a fraction of available XEPs. The XEPs are
> optional, if I get it right, but the user experience varies a lot with
> dfferent set of XEPs.
> 
> I found it difficult to get a list of supported XEPs by client and it is
> time consuming to understand what XEPs are for what feature. So a propasal
> I have is to do releases (of the standard).
> 
> A release contains a set of new (final) XEPs and a list of obsolete XEPs and
> all clients and servers that support XMPP version X have to implement this
> XEPs.

I tend to like this idea, as already mentioned in a past post in another 
thread:

https://mail.jabber.org/pipermail/standards/2018-February/034314.html
plus the context in
https://mail.jabber.org/pipermail/standards/2018-January/034181.html

I would extend it beyond Final (at least Draft) though :-).

> That would allow users to see, what a client is capable of. That would also
> allow client to show a message to there users about the client on the other
> end does not support XMPP version X and so there are some features that are
> not supported. 

Technically, we can already do that for each individual feature, thanks to 
XEP-0030 Service Discovery features. However, the trickiness is when Message 
Carbons, multiple devices and Message Archive Management come into play. 
Example:

You might detect that one of the two clients you’re currently talking to does 
not support Last Message Correction. Would you still allow the user to use 
LMC? The other device supports it; and since the messages will be archived, 
the user may be using other devices which support it, too.

> This also adds the abbility to generate some easy press
> coverage about the state of XMPP.

Possibly seconded.


I am still hoping for some feedback of the Council or other more experienced 
members of the community in regard to that.

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] xep-0313 missing features

[Lazar Otasevic]

Phillip,

I feel like we dont entirely understand each other. Are you sure you did
read and understood my post?

Getting array of ids gives you the order because ids should come in the
order respective messages are archived, and getting content is an extra
step above, unrelated to order. Content should be fetched by giving ANY set
of ids, like SQL SELECT...IN

Where in my statements you see that I don't treat ids as opaque?

Regards

On Sun, Mar 4, 2018 at 9:57 AM, Philipp Hörist  wrote:

> Hi,
>
> If you use MAM like that you will run into problems.
> if you request a specific ID you lose the Order information inside the
> Archive.
> your only option is to use the timestamp for ordering, but many messages
> can have the same timestamp.
>
> XEP:
> These IDs are strings that servers may construct in any manner, and
> clients must treat as opaque strings (e.g. there is no requirement for them
> to be numeric, sequenced or GUIDs)
>
>
> 2018-03-03 23:53 GMT+01:00 Lazar Otasevic :
>
>> Hi, I think I miss some features here:
>>
>> 1. fetching messages by giving a set of ids, also similar like xep-013
>>
>> Fetching message by id(s) is needed  for example when i have a custom
>> push notification with a given message id(s) and client needs to get that
>> one message asap and show it in the chat.
>>
>> 2. fetching message ids instead of entire messages, similar like "message
>> headers" in xep-013
>>
>> Fetching just message ids is harder to explain why its needed, but I
>> think its a must have if one wants to make an efficient and reliable local
>> message archive synced with server archive, and to make it as separate
>> module independent from the rest of the client. Basically by fetching
>> message ids we try to detect "holes" in our local archive and then we fill
>> that holes by doing step 1. I think this is a standard way of doing the
>> sync algorithm, and its mind boggling why its not here in MAM already.
>>
>> Is it possible to make it into reality and what would be the next steps
>> from my side?
>>
>> Thanks.
>>
>>
>>
>> ___
>> 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-0313 missing features

[Jonas Wielicki]

On Samstag, 3. März 2018 23:53:21 CET Lazar Otasevic wrote:
> Hi, I think I miss some features here:
> 
> 1. fetching messages by giving a set of ids, also similar like xep-013
> 
> Fetching message by id(s) is needed  for example when i have a custom push
> notification with a given message id(s) and client needs to get that one
> message asap and show it in the chat.

From my limited understanding of MAM, it should be possible if your custom 
push thing gives you the stanza-id instead of the message-id. Query by stanza-
id is kinda what MAM is really good at.


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] xep-0313 missing features

[Lazar Otasevic]

Matthew,

I may be repeating: every efficient sync algorithm needs iterating trough
ids and content separately. Of course we may make sync work without
iterating trough ids, but implementations like that are just terrible, too
complex, too coupled with the rest of design and not optimal.

I agree "back filling" feels wrong for someone and feels right for someone
else so its not an argument for technical discussion. Anyhow, direction of
iteration should be a client choice (server needs to provide both
directions possible).

Please keep in mind multi device scenarios. If one device misses a lot of
messages then back filling "feels" proper way for me - I want new messages
first (live messages also)

I thought the goal of XMPP is to make clients less complex and more
reliable? Why is adding two (basic) features counted as increasing
complexity? I say basic because those features were kind of existent back
in 2005 in xep-0013. Now we removed those features, why?


Thanks


On Sun, Mar 4, 2018 at 4:36 PM, Matthew Wild  wrote:

> Hi Lazar,
>
> On 3 Mar 2018 22:54, "Lazar Otasevic"  wrote:
> >
> > Hi, I think I miss some features here:
> >
> > 1. fetching messages by giving a set of ids, also similar like xep-013
> >
> > Fetching message by id(s) is needed  for example when i have a custom
> push notification with a given message id(s) and client needs to get that
> one message asap and show it in the chat.
>
> Why not just do a normal query? It feels wrong of a chat UI to show a
> message in a chat and later 'back-fill' the conversation. A message may
> easily be taken out of context this way.
>
> > 2. fetching message ids instead of entire messages, similar like
> "message headers" in xep-013
>
> I don't see why this is helpful. Why would a client want the stanza
> metadata but not the stanza?
>
> > Fetching just message ids is harder to explain why its needed, but I
> think its a must have if one wants to make an efficient and reliable local
> message archive synced with server archive, and to make it as separate
> module independent from the rest of the client. Basically by fetching
> message ids we try to detect "holes" in our local archive and then we fill
> that holes by doing step 1. I think this is a standard way of doing the
> sync algorithm, and its mind boggling why its not here in MAM already.
>
> Similarly I don't see what advantage this brings. Hole detection is
> already possible today with the current protocol, with no overhead of
> additionally fetching IDs and doing an inefficient list comparison.
>
> I really want to keep the XEP as simple as we can, and right now I don't
> see enough justification for adding these features.
>
> Regards,
> Matthew
>
> ___
> 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] UPDATED: XEP-0401 (Easy User Onboarding)

[XSF Editor]

Version 0.2.0 of XEP-0401 (Easy User Onboarding) has been released.

Abstract:
This document defines a protocol and URI scheme for user invitation in
order to allow a third party to register on a server. The goal of this
is to make onboarding for XMPP IM newcomers as easy as possible.

Changelog:
Used Data Forms for extension of In-Band Registration as required by
§ 4.
Added "defined condition" elements in error stanzas as required by  §
8.3.2.
Changed type of "invalid-token" error to "modify".
Fix namespacing of Ad-Hoc commands
Bump namespace to invite:1 (ms)

URL: https://xmpp.org/extensions/xep-0401.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Peter Saint-Andre]

On 3/4/18 1:27 AM, Florian Schmaus wrote:
> On 04.03.2018 02:30, Peter Saint-Andre wrote:
>>> On Mar 3, 2018, at 2:36 PM, Timothée Jaussoin  wrote:
>>> Hi,
>>>
>>> Thanks for the answers. I'm fine for the 3071 limitation, so we can set it 
>>> both for the Pubsub nodes id and Pubsub items it?
>>> If yes I'm ok to do a PR on the 0060 to specify that. I'm also wondering if 
>>> there is a specific way of declaring such string
>>> limitations, are you aware of any other XEPs that specify such things?
>>
>> As mentioned, I think this belongs in XEP-0030 but I suppose it can be 
>> defined in XEP-0060.
> 
> Could you elaborate why you think that it belongs in xep30? Are xep30
> item node's related to xep60 nodes? How fit xep60 item IDs into this?

The concept of a node was originally defined in XEP-0030, and the usage
in XEP-0060 borrowed from XEP-0030. The former is more fundamental and
thus I think it would be good to specify this in XEP-0030 (so that
"node" means the same thing across all protocol extensions). Or we could
resurrect XEP-0271:

https://xmpp.org/extensions/xep-0271.html

> Related: I wonder if we should specify string preparation for xep60 node
> and item ID strings. Same goes for the strings used by xep30, e.g.
> 's 'var' attribute value. Is any Unicode string a valid value
> for those? Or is this already specified somewhere and I just missed it?

If we want to specify this, I would recommend the UsernameCaseMapped
profile defined in RFC 8265.

However, there's a twist: if a node ID can be a full JID, then do we
want to apply the normal rules of RFC 7622 to all the JID parts, instead
of one uniform profile such as UsernameCaseMapped to the entire node ID?
For instance, the resourcepart of a JID is allowed to contain a much
wider range of Unicode characters than is allowed by the
UsernameCaseMapped profile of the PRECIS IdentifierClass (which we use
for the localpart).

Given that a node ID can be used for authorization decisions, I think
it's better to be conservative in what we accept (specifically, not
allow the wider range of characters in a resourcepart because
developers, and attackers, could get too "creative").

Peter



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

Re: [Standards] xep-0313 missing features

[Matthew Wild]

Hi Lazar,

On 3 Mar 2018 22:54, "Lazar Otasevic"  wrote:
>
> Hi, I think I miss some features here:
>
> 1. fetching messages by giving a set of ids, also similar like xep-013
>
> Fetching message by id(s) is needed  for example when i have a custom
push notification with a given message id(s) and client needs to get that
one message asap and show it in the chat.

Why not just do a normal query? It feels wrong of a chat UI to show a
message in a chat and later 'back-fill' the conversation. A message may
easily be taken out of context this way.

> 2. fetching message ids instead of entire messages, similar like "message
headers" in xep-013

I don't see why this is helpful. Why would a client want the stanza
metadata but not the stanza?

> Fetching just message ids is harder to explain why its needed, but I
think its a must have if one wants to make an efficient and reliable local
message archive synced with server archive, and to make it as separate
module independent from the rest of the client. Basically by fetching
message ids we try to detect "holes" in our local archive and then we fill
that holes by doing step 1. I think this is a standard way of doing the
sync algorithm, and its mind boggling why its not here in MAM already.

Similarly I don't see what advantage this brings. Hole detection is already
possible today with the current protocol, with no overhead of additionally
fetching IDs and doing an inefficient list comparison.

I really want to keep the XEP as simple as we can, and right now I don't
see enough justification for adding these features.

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

[Standards] Releases

[Gerion Entrup]

Hi,

I'm a user of XMPP and have very mixed experiences with different clients.

There are clients that do very well and implement a lot of availabe XEPs, but 
other clients only implement a fraction of available XEPs. The XEPs are 
optional, if I get it right, but the user experience varies a lot with 
dfferent set of XEPs.

I found it difficult to get a list of supported XEPs by client and it is time 
consuming to understand what XEPs are for what feature. So a propasal I have 
is to do releases (of the standard).

A release contains a set of new (final) XEPs and a list of obsolete XEPs and 
all clients and servers that support XMPP version X have to implement this 
XEPs.

That would allow users to see, what a client is capable of. That would also 
allow client to show a message to there users about the client on the other 
end does not support XMPP version X and so there are some features that are 
not supported. Or show a message in a client if the server does not support a 
current version. This also adds the abbility to generate some easy press 
coverage about the state of XMPP.

Cheers,
Gerion


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] xep-0313 missing features

[Philipp Hörist]

Hi,

If you use MAM like that you will run into problems.
if you request a specific ID you lose the Order information inside the
Archive.
your only option is to use the timestamp for ordering, but many messages
can have the same timestamp.

XEP:
These IDs are strings that servers may construct in any manner, and clients
must treat as opaque strings (e.g. there is no requirement for them to be
numeric, sequenced or GUIDs)


2018-03-03 23:53 GMT+01:00 Lazar Otasevic :

> Hi, I think I miss some features here:
>
> 1. fetching messages by giving a set of ids, also similar like xep-013
>
> Fetching message by id(s) is needed  for example when i have a custom push
> notification with a given message id(s) and client needs to get that one
> message asap and show it in the chat.
>
> 2. fetching message ids instead of entire messages, similar like "message
> headers" in xep-013
>
> Fetching just message ids is harder to explain why its needed, but I think
> its a must have if one wants to make an efficient and reliable local
> message archive synced with server archive, and to make it as separate
> module independent from the rest of the client. Basically by fetching
> message ids we try to detect "holes" in our local archive and then we fill
> that holes by doing step 1. I think this is a standard way of doing the
> sync algorithm, and its mind boggling why its not here in MAM already.
>
> Is it possible to make it into reality and what would be the next steps
> from my side?
>
> Thanks.
>
>
>
> ___
> 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] What is the size limit of node and item ids in XEP-0060: Publish-Subscribe?

[Florian Schmaus]

On 04.03.2018 02:30, Peter Saint-Andre wrote:
>> On Mar 3, 2018, at 2:36 PM, Timothée Jaussoin  wrote:
>> Hi,
>>
>> Thanks for the answers. I'm fine for the 3071 limitation, so we can set it 
>> both for the Pubsub nodes id and Pubsub items it?
>> If yes I'm ok to do a PR on the 0060 to specify that. I'm also wondering if 
>> there is a specific way of declaring such string
>> limitations, are you aware of any other XEPs that specify such things?
> 
> As mentioned, I think this belongs in XEP-0030 but I suppose it can be 
> defined in XEP-0060.

Could you elaborate why you think that it belongs in xep30? Are xep30
item node's related to xep60 nodes? How fit xep60 item IDs into this?

Related: I wonder if we should specify string preparation for xep60 node
and item ID strings. Same goes for the strings used by xep30, e.g.
's 'var' attribute value. Is any Unicode string a valid value
for those? Or is this already specified somewhere and I just missed it?

- Florian




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