Re: [Standards] Fwd: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames
On Thu Mar 1 22:51:09 2012, Peter Saint-Andre wrote: On 3/1/12 3:48 PM, Dave Cridland wrote: > Consider: That's why I'm saying we might want a separate PRECIS profile for nicks. Right, but I'm saying we don't need a rock-solid profile - just some sensible guidelines will do just as well. That is, we don't need to worry that nicknames compare consistently between servers for interoperability, we just need to recommend that servers handle the security implications of nicknames. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Fwd: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames
On 3/1/12 3:48 PM, Dave Cridland wrote: > Consider: That's why I'm saying we might want a separate PRECIS profile for nicks. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Fwd: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames
On Thu Mar 1 22:28:57 2012, Peter Saint-Andre wrote: FYI, there's discussion happening on the SIMPLE WG list about internationalization of nicknames in chatrooms. There might be value in pursuing a common approach. Please follow up on the sim...@ietf.org list: I've long since dropped off the simple list, but feel free to forward this note as appropriate - I'm mostly raising this point now since it happens to have come up. I do think our use of resourceprep is often a little silly. Consider: 1) Actual resource parts are basically opaque identifiers, and comparing them as octet strings without normalization would (and, as far as I can tell, does) work just fine. If people are actually typing these things in - where you'd need resourceprep to normalize - then they're probably doing something wrong. 2) When they're used as chatroom nicknames, on the other hand, resourceprep is nothing like enough. As things stand, if a user joins as "dwd", another can join as "Dwd" - which is mildly confusing - or "dwd " - which is downright nasty. I think it would be sensible for a XEP-0045 implementation to reject (with a conflict) or change (by adding "~1" or similar) the nickname in these cases. Arguably, the ability to closely mimic other chatroom occupants without even recourse to Cherokee is a security flaw in XEP-0045, but luckily it's not one that requires a single interoperable solution - the key is that an implementation should be able to normalize (or rationalize, if you prefer) nicknames in any way it sees fit, by overriding the nickname on join (or change). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] Fwd: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames
FYI, there's discussion happening on the SIMPLE WG list about internationalization of nicknames in chatrooms. There might be value in pursuing a common approach. Please follow up on the sim...@ietf.org list: https://www.ietf.org/mailman/listinfo/simple Original Message Subject: Re: [Simple] SIMPLE chat: Internationalization and normalization of nicknames Date: Thu, 01 Mar 2012 15:26:00 -0700 From: Peter Saint-Andre To: Ben Campbell CC: Simple WG On 3/1/12 3:12 PM, Ben Campbell wrote: > > On Mar 1, 2012, at 3:55 PM, Miguel A. Garcia wrote: > >> Dear all: >> >> I am trying to address the last known issue of the SIMPLE chat >> draft. This came through Enrico Marocco's Appsdir review, and the >> comment was: >> >> The document doesn't describe allowed characters in Nicks and any >> normalization that needs to be applied. >> >> So, I got advice from Alexy Melnikov, indicating that we should >> take a look at the ResourcePrep in: >> http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ >> >> The idea is to inspire on the ResourcePrep and adapted to Nicknames >> in SIMPLE chat. However, there is a dependency on the completion of >> the Precis Framework: >> https://datatracker.ietf.org/doc/draft-ietf-precis-framework/ >> >> This means that SIMPLE chat will need to add a normative dependency >> to the Precis Framework, and if SIMPLE chat is approved and arrives >> to the RFC Editor before the Precis Framework, it will stay there >> until the framework reaches the RFC editor. > > (as individual) > > I concur with this approach in general, although I think we will find > some differences between the Resource parts in 6122/6122bis and the > use of nicknames in simple-chat. In particular: > > 1) A resource part identifies something. That makes uniqueness and > comparisons fairly important. OTOH, a nickname is really for human > display purposes. We still need to be able to compare them for > reservations to work. And the human readability part means we should > at least mention character confusion issues. In the chatroom context, XMPP resourceparts are mostly used for display purposes but also for some authorization decisions (e.g., we can kick people based on their nickname). As far as I understand it, the uses are really quite similar in XMPP chatrooms and SIMPLE chatrooms. > 2) The 6122bis resource parts live inside URIs, while simple-chat > nicknames are just strings. Well, we don't really use URIs in XMPP. Probably you mean JIDs (JabberIDs). In that case, yes, they are used sometimes for addressing in XMPP chatrooms (e.g., to send a private message to another occupant). > I'm not sure that these differences really change the outcome > much--they're just things to think about. Although I think that XMPP resourceparts *as they are used in chatrooms* are quite similar to SIMPLE nicknames, resourceparts are used in other contexts (e.g., as device/connection identifiers) so the resourceprep replacement that's developed in the XMPP WG won't be quite what you need anyway. However, there probably is value in thinking about nicks in general, because it's possible that we could define the same PRECIS profile for use in both XMPP chatrooms (XEP-0045) and SIMPLE chatrooms. A common approach might be good. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Simple mailing list sim...@ietf.org https://www.ietf.org/mailman/listinfo/simple
Re: [Standards] Advice on XEP-0301 Mass-Market Use Cases (if XEP-0301 added to Adium/Miranda within 12 months)
Hello Bernard, Yes -- There would likely ideally be both a per-session activation mechanism, as well as a global auto-accept setting in the software's own preferences. -- Mainstream clients (i.e. Adium, Pidgin) would presumably have auto-accept disabled (by default) in a default software installation, and likely provide an activation feature (a button, and/or a popup notification similar to "Real-text is available. Click enable to activate", etc.) when the software determines the other end is detected to support real-time text. Users who always wants RTT enabled, can then go into preferences and turn on auto-accept. -- Assistive clients targeted to the deaf market would presumably have auto-accept enabled in a default software installation, and not need to click a button to activate RTT. Mainstream clients (autoaccept turned off) suddenly receiving RTT, would prompt the user if they want to enable sending back of RTT. MUC easily accepts RTT, but the dynamics of activating RTT for a MUC can become significantly complicated. For the interim (at the moment) we assume it's safe to just broadcast RTT into a MUC we know allows RTT (i.e. deaf chat rooms, next generation 9-1-1 experimental system, etc) because these are usually niche situations, with specialized clients pre-configured to specialized chat rooms. If RTT becomes popular this topic will need to be revisted. A one-on-one chat that already has RTT, that gets converted to MUC, would be assumed to continue RTT. RTT works in a mixed-mode fashion (RTT clients and non-RTT clients) with group chat rooms, documented in: http://www.marky.com/realjabber/XMPP-RTT-Supplement_2011-06-17.pdf (supplemental document that covers discussion about RTT in MUC) Right now, the email I wrote is chiefly targeted at non-MUC situations, on the best-practices. I think I found a situation that will be 100% compatible with MUC. There has been further thought and internal discussion on the matter -- Thanks, Mark Rejhon On Thu, Mar 1, 2012 at 2:34 PM, Bernard Aboba wrote: > With respect to the Alice/Bob exchange, is there an expectation that the > RTT preference would persist? Or is it just a choice for that particular > conversation? > > There is also the MUC scenario. How does discovery fit into this case? > It also seems that there will be some rooms where RTT would want to be on > by default (e.g. emergency use case). > > On Tue, Feb 28, 2012 at 7:06 PM, Mark Rejhon wrote: > >> To the Stadards group, >> >> I bring up a question separate from the Session Handling. >> (many questions have already been answered -- thank you very much) >> >> *Scenario: *XEP-0301 real-time text gets added to a mainstream client >> such as Pidgin or Miranda within 12 months. >> >> *Question: *What is the simplest possible and easiest method of safely >> introduce real-time text politely to a mainstream client, in a >> non-intrusive manner? (i.e. privacy) >> Especially if one end has RTT enabled by default (i.e. intentionally >> enabled by user), and the other end has RTT disabled by default (i.e. >> default installation) >> >> *Details of Scenarios:* >> - People don't normally expect their typing to be transmitted in real >> time. Therefore, feature shold be off by default in such mainstream >> clients. >> - However, it should be easy as possible to enable. Therefore, such >> mainstream clients will always advertise XEP-0301 compatibility via disco >> (section 5) but not necessarly enable the transmission of outgoing >> XEP-0301, including for privacy reasons. >> - Some people, such as deaf users, will want to change the software >> preference to permanently allow XEP-0301. >> (i.e. in software preferences) >> - However, even when disabled by default, we want users to make it easy >> for XEP-0301-aware recipients to enable the feature for responding to other >> XEP-0301 clients. >> (i.e. per-chat-session activation feature, such as a button) >> >> *Potential popularity in 10 years* >> Just like all television sets have a closed caption decoder, and is >> usually turned off by default, but easily turned on -- eventually, we hope >> XEP-0301 becomes mainstream within 10 years, as a replacement for obsolete >> deaf TDD/TTY teletypewriters. In even my limited testing (non-deaf >> family, friends, coworkers, etc), I found that once they understood what >> RTT was, it was a more popular feature than audio and video. So RTT has a >> lot of potential to improve the IM experience, even if it's an option >> feature enabled only a few percent of the time. Although more scientific >> surveys need to be done once it's already a part of Adium/Miranda/etc, it >> shows that sometimes people like to switch to the conversational mode via >> RTT rather than via audio, since they can talk very conversationally >> without making noise. Other times, people are in an asynchronous mood, >> like text messaging, regular instant messages, or email. But it >> apparently shows that there's more fr
Re: [Standards] Advice on XEP-0301 Mass-Market Use Cases (if XEP-0301 added to Adium/Miranda within 12 months)
With respect to the Alice/Bob exchange, is there an expectation that the RTT preference would persist? Or is it just a choice for that particular conversation? There is also the MUC scenario. How does discovery fit into this case? It also seems that there will be some rooms where RTT would want to be on by default (e.g. emergency use case). On Tue, Feb 28, 2012 at 7:06 PM, Mark Rejhon wrote: > To the Stadards group, > > I bring up a question separate from the Session Handling. > (many questions have already been answered -- thank you very much) > > *Scenario: *XEP-0301 real-time text gets added to a mainstream client > such as Pidgin or Miranda within 12 months. > > *Question: *What is the simplest possible and easiest method of safely > introduce real-time text politely to a mainstream client, in a > non-intrusive manner? (i.e. privacy) > Especially if one end has RTT enabled by default (i.e. intentionally > enabled by user), and the other end has RTT disabled by default (i.e. > default installation) > > *Details of Scenarios:* > - People don't normally expect their typing to be transmitted in real > time. Therefore, feature shold be off by default in such mainstream > clients. > - However, it should be easy as possible to enable. Therefore, such > mainstream clients will always advertise XEP-0301 compatibility via disco > (section 5) but not necessarly enable the transmission of outgoing > XEP-0301, including for privacy reasons. > - Some people, such as deaf users, will want to change the software > preference to permanently allow XEP-0301. > (i.e. in software preferences) > - However, even when disabled by default, we want users to make it easy > for XEP-0301-aware recipients to enable the feature for responding to other > XEP-0301 clients. > (i.e. per-chat-session activation feature, such as a button) > > *Potential popularity in 10 years* > Just like all television sets have a closed caption decoder, and is > usually turned off by default, but easily turned on -- eventually, we hope > XEP-0301 becomes mainstream within 10 years, as a replacement for obsolete > deaf TDD/TTY teletypewriters. In even my limited testing (non-deaf > family, friends, coworkers, etc), I found that once they understood what > RTT was, it was a more popular feature than audio and video. So RTT has a > lot of potential to improve the IM experience, even if it's an option > feature enabled only a few percent of the time. Although more scientific > surveys need to be done once it's already a part of Adium/Miranda/etc, it > shows that sometimes people like to switch to the conversational mode via > RTT rather than via audio, since they can talk very conversationally > without making noise. Other times, people are in an asynchronous mood, > like text messaging, regular instant messages, or email. But it > apparently shows that there's more frequently a mood to be conversational > via RTT than via audio or video, from this limited testing. Thus, we need > to be prepared for the potential possibility that it may show up in > mainstream clients. > NOTE: We've also got a new logo for real-time text at www.fasttext.orgwhich > we'll be starting to use in the next 12 months for future programming. > > Advertising XEP-0301 capability is done by a caps detection. Presumably, > this will always be the case in all clients that supports XEP-0301. > > We see three situations where chat is activated between two XEP-0301 aware > clients: > 1. Both clients advertise XEP-0301 capability, but does not send XEP-0301 > by default. > 2. Both clients advertise XEP-0301 capability, but only recipient sends > XEP-0301 by default. > 3. Both clients advertise XEP-0301 capability, but only sender sends > XEP-0301 by default. > We want to make it easy for both ends to start sending RTT in scenario 2 > and 3, even if disabled by default. > > *Example "Accessible" future use case **(which will happen!):* > -- Alice is a deaf user, using a year 2014 build of Adium. She has > XEP-0301 enabled. > -- Bob is a hearing user, not aware of real-time text, but is using a year > 2014 build of Pidgin that has XEP-0301 support but does not transmit RTT by > default. > -- Alice sends a message to Bob. She immediately sends RTT. Her typing > is transmitted in real time. > -- Bob's client software detects this but does not automatically send > Bob's typing in real time. > *The big question: What should happen afterwards?* > > *Possible Ideas/Methods of negotiating RTT activation* > - XEP-0020? Bob instant messaging client, should be able to activate a > session negotiation feature. As you remember, we added an XEP-0020 session > negotiation feature in Version 0.0.1 of XMPP-RTT, but it got removed from > Version 0.0.2 of XMPP-RTT. It is overkill/complesx. > - Jingle? I think it's still overkill, since we want to operate 100% > in-band > - XEP-0030? We should always advertise XEP-0301 even if the client > doesn't send outgoing RTT by default. T
Re: [Standards] NEW: XEP-0312 (PubSub Since)
Hi! XMPP Extensions Editor wrote: > Version 0.1 of XEP-0312 (PubSub Since) has been released. Great that this is approached by somebody! > Abstract: This specification defines a publish-subscribe feature that > enables a subscriber to automatically receive pubsub and PEP > notifications since the last logout time of a specific resource. For buddycloud we use MAM[1] so far but gave the problem some thought before. 1. Specifying a relative timespan instead of absolute timestamps avoids the need for global clock synchronization. That is smart. Until now we used the timestamp of the latest pubsub notification (ATOM payload). 2. I've been very reluctant to employ for requesting history, especially presence broadcasts. Presence will be resent upon changing the online status & text. It could be important to exclude the XEP-0312 information in all but the very first presence stanza. Moreover, presence can be redistributed by a user's server. This happens only on presence probes, right? Is this still safe enough? What if the pubsub service needs to be restarted, subsequently probing for presence of its subscribed users? It will needlessly replay history. Admittedly in buddycloud clients only communicate with their one "inbox" pubsub service, so the MAM doesn't add much complexity. I can see a reason for when dealing with many entities though. 3. MAM specifies replayed notifications to be sent in XEP-0297ish envelopes, despite that there's no forwarding going on. The history sender is the notification source. XEP-0312 doesn't specify that and I guess there is no reason for it? 4. RSM with and multiple stanzas in response needs to be specified clearly. RSM is only straight-forward for -based extensions such as MAM. Stephan [1] http://doomsong.co.uk/extensions/render/message-archive-management.html
Re: [Standards] NEW: XEP-0312 (PubSub Since)
Very expected XEP but very ambiguous: 1. "The service MAY include Result Set Management [4] data so that the subscriber can page through the set of interim notifications, as described in Section 6.5.3 of XEP-0060." How can it be done if it will send separate events in stanzas? 2. "The service SHOULD NOT include items that were removed from the node" That's ok but what about retracts and other events which were fired during the user's absence? I mean, I might to want to know which already discovered items were retracted. 3. There is no possibility to retrieve notification by the query. It's needed, for example, for nodes which has no user's presence subscription. 4. Not important subjective opinion: it will be more useful to operate with some "revision" and not with time. Then clients will be allowed to track if they missed something in case of connection troubles or if some other resource has got higher priority and intercepted events. On 03/01/2012 09:13 AM, XMPP Extensions Editor wrote: > Version 0.1 of XEP-0312 (PubSub Since) has been released. > > Abstract: This specification defines a publish-subscribe feature that enables > a subscriber to automatically receive pubsub and PEP notifications since the > last logout time of a specific resource. > > Changelog: Initial published version. (psa) > > Diff: N/A > > URL: http://xmpp.org/extensions/xep-0312.html > > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
