Re: [Standards] XEP-0388 SASL2: #1 client-identifier
On Sat, 19 Nov 2022 at 19:02, Dave Cridland wrote: > On Sat, 19 Nov 2022 at 18:34, Matthew Wild wrote: >> >> On Sat, 19 Nov 2022 at 15:14, Dave Cridland wrote: >> > >> > I commented about this on the PR, but that seems to have been dismissed, >> > so again, for the list: >> > >> > * I'm not convinced this is required to be a mandatory feature of SASL2, >> > despite its obvious utility, but I'm not going to argue very strongly that >> > it shouldn't be. >> > * I *am* convinced that an id attribute has to be mandatory (and SHOULD be >> > a UUIDv4). >> > * I am also convinced that the human-readable software information >> > shouldn't be mandatory. >> >> I agree that neither of these should be mandatory, and that's why they >> aren't. If there are reasons for clients not to include them, they >> don't have to. Not including them may have consequences - e.g. the >> FAST spec depends on the client id being present so wouldn't be >> usable, and if the software info isn't included then the user will be >> less informed about what is connecting to their account. For such >> reasons, it is recommended that they are included. But mandatory, no. >> > > Clients SHOULD also include a user-agent/> element, informing the > server about the connecting client. The 'id' > attribute is RECOMMENDED, and if present it contains a unique stable > identifier for the client installation. This allows > the server to provide functionality such as deriving stable resource > identifiers (see ). The child elements software/> and > device/> contain text descriptions of the client software and the device > it is installed on. These allow the server to keep the user informed > about what devices are connected to their account. Servers MUST NOT expose > this information to other entities (such functionality is available in > if required). > > So... > > The isn't mandatory, no, and I stand corrected on my first > point. I'm not convinced this should be a part of SASL2, as such - but to be > clear, I'm not convinced it shouldn't be either. > > But if included, then the id isn't mandatory, which was my second point - I > think the id needs to be a MUST for this to have value, whether or not the > software info is supplied. > > The child elements aren't explicitly mandatory or optional in this paragraph, > but are included in every example. I'd assumed they were mandatory based on > this and the phrasing "The child elements ... contain" - no "if present" as > with the id attribute. Certainly it's very unclear if they're recommended, > optional, or mandatory. Is there some other text I'm missing? It's not in the > schema, as far as I can find, either. That makes sense, thanks. I'll provide updated wording which clarifies things. Taking each piece of information separately, the intent was that each of them SHOULD be included by the client. However any or all could be omitted with reason. I don't know how I feel about making the inclusion of 'id' a MUST. If a client can't or won't provide a stable identifier for whatever reason, I'd sooner have such a client omit it entirely than, for example, provide a changing id on every connection. I'm in favour of saying that the identifier SHOULD/MUST be a UUIDv4. That would alleviate some concerns I had about clients putting inappropriate identifiers there, such as those that can be used to identify the user/device in other contexts. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388 SASL2: #1 client-identifier
On Sat, 19 Nov 2022 at 18:34, Matthew Wild wrote: > On Sat, 19 Nov 2022 at 15:14, Dave Cridland wrote: > > > > I commented about this on the PR, but that seems to have been dismissed, > so again, for the list: > > > > * I'm not convinced this is required to be a mandatory feature of SASL2, > despite its obvious utility, but I'm not going to argue very strongly that > it shouldn't be. > > * I *am* convinced that an id attribute has to be mandatory (and SHOULD > be a UUIDv4). > > * I am also convinced that the human-readable software information > shouldn't be mandatory. > > I agree that neither of these should be mandatory, and that's why they > aren't. If there are reasons for clients not to include them, they > don't have to. Not including them may have consequences - e.g. the > FAST spec depends on the client id being present so wouldn't be > usable, and if the software info isn't included then the user will be > less informed about what is connecting to their account. For such > reasons, it is recommended that they are included. But mandatory, no. > > Clients SHOULD also include a user-agent/> element, informing the server about the connecting client. The 'id' attribute is RECOMMENDED, and if present it contains a unique stable identifier for the client installation. This allows the server to provide functionality such as deriving stable resource identifiers (see ). The child elements software/> and device/> contain text descriptions of the client software and the device it is installed on. These allow the server to keep the user informed about what devices are connected to their account. Servers MUST NOT expose this information to other entities (such functionality is available in if required). So... The isn't mandatory, no, and I stand corrected on my first point. I'm not convinced this should be a part of SASL2, as such - but to be clear, I'm not convinced it shouldn't be either. But if included, then the id isn't mandatory, which was my second point - I think the id needs to be a MUST for this to have value, whether or not the software info is supplied. The child elements aren't explicitly mandatory or optional in this paragraph, but are included in every example. I'd assumed they were mandatory based on this and the phrasing "The child elements ... contain" - no "if present" as with the id attribute. Certainly it's very unclear if they're recommended, optional, or mandatory. Is there some other text I'm missing? It's not in the schema, as far as I can find, either. > 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 ___
Re: [Standards] XEP-0388 SASL2: #1 client-identifier
On Sat, 19 Nov 2022 at 15:14, Dave Cridland wrote: > > I commented about this on the PR, but that seems to have been dismissed, so > again, for the list: > > * I'm not convinced this is required to be a mandatory feature of SASL2, > despite its obvious utility, but I'm not going to argue very strongly that it > shouldn't be. > * I *am* convinced that an id attribute has to be mandatory (and SHOULD be a > UUIDv4). > * I am also convinced that the human-readable software information shouldn't > be mandatory. I agree that neither of these should be mandatory, and that's why they aren't. If there are reasons for clients not to include them, they don't have to. Not including them may have consequences - e.g. the FAST spec depends on the client id being present so wouldn't be usable, and if the software info isn't included then the user will be less informed about what is connecting to their account. For such reasons, it is recommended that they are included. But mandatory, no. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388 SASL2: #1 client-identifier
On Sat, Nov 19, 2022 at 4:15 PM Dave Cridland wrote: > * I *am* convinced that an id attribute has to be mandatory (and SHOULD be a > UUIDv4). I agree. That also gives it an automatic size limit > * I am also convinced that the human-readable software information shouldn't > be mandatory. I'm not sure it is. But if it is I agree that it shouldn’t ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0388 SASL2: #1 client-identifier
I commented about this on the PR, but that seems to have been dismissed, so again, for the list: * I'm not convinced this is required to be a mandatory feature of SASL2, despite its obvious utility, but I'm not going to argue very strongly that it shouldn't be. * I *am* convinced that an id attribute has to be mandatory (and SHOULD be a UUIDv4). * I am also convinced that the human-readable software information shouldn't be mandatory. On Sat, 22 Oct 2022 at 22:29, Thilo Molitor wrote: > I'm trying to rephrase and sum up here, what MattJ already said: https:// > mail.jabber.org/pipermail/standards/2022-October/038998.html > > Stable client-identifier: > This allows per-device tokens or even passwords. > It allows to present users with a list of devices that currently have > access > to their account. > > Software and Device: > The software and device information allows users to better identify their > clients than just using the opaque client-identifier: "Conversations on > Kiva's > iPhone" is far more descriptive than "0ba15cd[...]". > > @MattJ: Add it, if I'm missing something here > > -tmolitor > > > > ___ > 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] XEP-0388 SASL2: #1 client-identifier
I'm trying to rephrase and sum up here, what MattJ already said: https:// mail.jabber.org/pipermail/standards/2022-October/038998.html Stable client-identifier: This allows per-device tokens or even passwords. It allows to present users with a list of devices that currently have access to their account. Software and Device: The software and device information allows users to better identify their clients than just using the opaque client-identifier: "Conversations on Kiva's iPhone" is far more descriptive than "0ba15cd[...]". @MattJ: Add it, if I'm missing something here -tmolitor ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
