[standards-jig] unsubscribe

Kent Wang kwang at kwang.org
Fri Dec 5 22:16:50 UTC 2003


> Send Standards-JIG mailing list submissions to
> 	standards-jig at jabber.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mailman.jabber.org/listinfo/standards-jig
> or, via email, send a message with subject or body 'help' to
> 	standards-jig-request at jabber.org
>
> You can reach the person managing the list at
> 	standards-jig-admin at jabber.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Standards-JIG digest..."
>
>
> Today's Topics:
>
>   1. Re: Re: [Foundation] Motion for Last Call - Chat State
>   Notifications (JEP-0085) (Alexander Gnauck) 2. Re: [Foundation]
>   Motion for Last Call - Chat State Notifications (JEP-0085) (Julian
>   Missig) 3. Re: Re: [Foundation] Motion for Last Call - Chat
>       State Notifications (JEP-0085) (Sebastiaan Deckers)
>   4. UPDATED: JEP-0045 (Multi-User Chat) (Peter Saint-Andre)
>   5. Re: Re: [Foundation] Motion for Last Call - Chat State
>   Notifications (JEP-0085) (Nathan Walp) 6. RE: UPDATED: JEP-0045
>   (Multi-User Chat) (Heiner Wolf)
>   7. Re: UPDATED: JEP-0045 (Multi-User Chat) (David Sutton)
>   8. RE: UPDATED: JEP-0045 (Multi-User Chat) (Heiner Wolf)
>
> --__--__--
>
> Message: 1
> To: standards-jig at jabber.org
> From: "Alexander Gnauck" <gnauck at myjabber.net>
> Date: Thu, 4 Dec 2003 19:33:40 +0100
> Subject: [standards-jig] Re: Re: [Foundation] Motion for Last Call -
> Chat State Notifications (JEP-0085) Reply-To: standards-jig at jabber.org
>
>> This is an interesting email... thanx for posting.
>> I had never thought about the possible co-existance of -22 (but NOT
>> composing) and chat-states but it does make a lot of sense.
>>
>> The reason why this JEP is better than simple -22 is your third
>> bullet point.. It allows more states than JEP-22 does.
>
> its no big deal to add additional states to JEP-22
>
> Alex
>
>
>
>
> --__--__--
>
> Message: 2
> Cc: standards-jig at jabber.org
> From: Julian Missig <julian at jabber.org>
> Date: Thu, 4 Dec 2003 14:19:22 -0500
> To: members at jabber.org
> Subject: [standards-jig] Re: [Foundation] Motion for Last Call - Chat
> State Notifications (JEP-0085) Reply-To: standards-jig at jabber.org
>
> On 4 Dec, 2003, at 10:57, Sebastiaan Deckers wrote:
>
>> + Introduces new conversation modes besides composing: active,
>> inactive, gone
>
> I've yet to hear a compelling argument that these new states are
> actually necessary and beneficial to the user. While notification of
> typing is a slight violation of privacy, I certainly don't want people
> know when their window is active/inactive or when I've closed it.
> Really I think it would just end up making some people feel bad, and I
> don't think there's a clear benefit to it.
>
> Julian
>
>
> --__--__--
>
> Message: 3
> Date: Thu, 04 Dec 2003 21:22:05 +0100
> From: Sebastiaan Deckers <cbas at rhymbox.com>
> To: standards-jig at jabber.org
> Cc: members at jabber.org
> Subject: Re: [standards-jig] Re: [Foundation] Motion for Last Call -
> Chat
> State Notifications (JEP-0085)
> Reply-To: standards-jig at jabber.org
>
> Julian,
>
> No one is being forced to support this.  Perhaps you can make it
> optional in your clients.  Perhaps not implement it at all.
>
> Loss of privacy is the same argument used a long time ago against the
> composing event and could just as well be used against the displayed
> event. People thought privacy was going to be lost forever, but in
> reality it  turned out to be quite helpful in a conversation.
> The fact is that you can not rely on this information being accurate
> for  spying purposes.  People might have it turned off, there might be
> a bug  in the client, someone may be tricking you into thinking that
> they are  reading the conversation, etc.
>
> ---
>
> Here is one example where the gone event would help.
>
> [ Alice and Bob have had a long conversation ]
> Alice says: I have to go.  It was nice talking to you.  TTYL
>
> Now Bob is thinking: Shit, do I reply "bye" and risk having the message
>  queued in offline storage because she's really already offline?  Then
> she might not get it until the next day, at which time she will be
> confused as to why I said "bye".  Or do I not send anything and keep
> Alice waiting for me to aknowledge, making me seem like a jerk?
>
> Solution: Alice was in a hurry and closed the window.  Her client send
> the "gone" chatstate and Bob saw that he did not need to acknowledge
> her  departure.
>
> Note: This only works if Alice closes her chatwindow, making the client
>  tell Bob not to bother replying because she's left already.  Call it
> implicit messaging if you will. :-)
>
>
> -Sebastiaan
>
>
> Julian Missig wrote:
>
>> On 4 Dec, 2003, at 10:57, Sebastiaan Deckers wrote:
>>
>>> + Introduces new conversation modes besides composing: active,
>>> inactive, gone
>>
>>
>> I've yet to hear a compelling argument that these new states are
>> actually necessary and beneficial to the user. While notification of
>> typing is a slight violation of privacy, I certainly don't want people
>>  know when their window is active/inactive or when I've closed it.
>> Really I think it would just end up making some people feel bad, and I
>>  don't think there's a clear benefit to it.
>>
>> Julian
>
>
>
> --__--__--
>
> Message: 4
> Date: Thu, 4 Dec 2003 18:13:08 -0600
> From: Peter Saint-Andre <stpeter at jabber.org>
> To: standards-jig at jabber.org
> Subject: [standards-jig] UPDATED: JEP-0045 (Multi-User Chat)
> Reply-To: standards-jig at jabber.org
>
> At the recent IETF meeting in Minneapolis, I heard one thing that I
> through would be useful in MUC: the ability to request voice in a
> moderated room without poking any specific room admin. This might be
> especially useful in a large room. So I've added a little protocol for
> that in JEP-0045. Also I've added a mapping of IRC-style commands to
> MUC protocols for clients that want to implement that.
>
> http://www.jabber.org/jeps/jep-0045.html
>
> We really will be done with this soon. Maybe we need to make it Final
> so I stop messing around with it....
>
> Oh, and I'm not wedded to the voice request protocol, just thought it
> would be useful. Let's discuss on the list here.
>
> Peter
>
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.php
>
>
> --__--__--
>
> Message: 5
> Date: Fri, 5 Dec 2003 00:44:43 -0500
> From: Nathan Walp <faceprint at faceprint.com>
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] Re: [Foundation] Motion for Last Call -
> Chat State Notifications (JEP-0085) Reply-To: standards-jig at jabber.org
>
>
> --3lcZGd9BuhuYXNfi
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, Dec 04, 2003 at 10:43:13AM -0700, Peter Millard wrote:
>> The reason why this JEP is better than simple -22 is your third bullet
>> po=
> int..
>> It allows more states than JEP-22 does.
>
> The only "extra" state i've ever wanted was the "typed" state (user was
> typing a message, but has paused), which doesn't exist in either JEP.
>
>
> Nathan
>
> --=20
> Nathan Walp             || faceprint at faceprint.com
> GPG Fingerprint:        ||   http://faceprint.com/
> 5509 6EF3 928B 2363 9B2B  DA17 3E46 2CDC 492D DB7E
>
>
> --3lcZGd9BuhuYXNfi
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQE/0BtLPkYs3Ekt234RAjC9AKC+k8xrGZWYylvX29baDwunFMPD1gCfWp/J
> M4xhQ6jrdSUhtCKvqo/giZk=
> =n8qW
> -----END PGP SIGNATURE-----
>
> --3lcZGd9BuhuYXNfi--
>
> --__--__--
>
> Message: 6
> Subject: RE: [standards-jig] UPDATED: JEP-0045 (Multi-User Chat)
> Date: Fri, 5 Dec 2003 11:06:07 +0100
> From: "Heiner Wolf" <wolf at bluehands.de>
> To: <standards-jig at jabber.org>
> Reply-To: standards-jig at jabber.org
>
> Hi,
>
> writing JEP Virtual Presence I reviewed the use of JIDs in chat rooms.
> I can get rid of JIDs in anonymous rooms, if the room would be able to
> fetch server storage on behalf of the client. So, clients do not know
> each other's JID, but get access to each other's server storage through
> the room.
>
> I propose that the room be a proxy, like:
>  client -> room:
>  <iq type='get' to='room at server/nickname'>
>    <query xmlns='storage:client:something'/>
>  </iq>
>
>  room -> server of the client:
>  <iq type='get' to='user at jid'>
>    <query xmlns='storage:client:something'/>
>  </iq>
>
>  server of the client -> room:
>  <iq type='result' to='room at server'>
>    <query xmlns='storage:client:something'>DATA<query>
>  </iq>
>
>  room -> client:
>  <iq type='result' to='room at server/nickname'>
>    <query xmlns='storage:client:something'>DATA<query>
>  </iq>
>
> where only the first stanza is kind of new, but implemented easily.
>
> Probably needs configuration if the room is willing to take the traffic
> load, off by default, etc.
>
> hw
> --
> Dr. Klaus H. Wolf
> bluehands GmbH & Co.mmunication KG
> http://www.bluehands.de/people/hw
> +49 (0721) 16108 75
>
>
>> -----Original Message-----
>> From: standards-jig-admin at jabber.org
>> [mailto:standards-jig-admin at jabber.org]On Behalf Of Peter Saint-Andre
>> Sent: Friday, December 05, 2003 1:13 AM
>> To: standards-jig at jabber.org
>> Subject: [standards-jig] UPDATED: JEP-0045 (Multi-User Chat)
>>
>>
>> At the recent IETF meeting in Minneapolis, I heard one thing that I
>> through would be useful in MUC: the ability to request voice in a
>> moderated room without poking any specific room admin. This might be
>> especially useful in a large room. So I've added a little protocol for
>> that in JEP-0045. Also I've added a mapping of IRC-style
>> commands to MUC
>> protocols for clients that want to implement that.
>>
>> http://www.jabber.org/jeps/jep-0045.html
>>
>> We really will be done with this soon. Maybe we need to make
>> it Final so
>> I stop messing around with it....
>>
>> Oh, and I'm not wedded to the voice request protocol, just thought it
>> would be useful. Let's discuss on the list here.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> Jabber Software Foundation
>> http://www.jabber.org/people/stpeter.php
>>
>> _______________________________________________
>> Standards-JIG mailing list
>> Standards-JIG at jabber.org
>> http://mailman.jabber.org/listinfo/standards-jig
>>
>
> --__--__--
>
> Message: 7
> Date: Fri, 5 Dec 2003 07:19:05 -0600
> From: David Sutton <jabber at dsutton.legend.uk.com>
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] UPDATED: JEP-0045 (Multi-User Chat)
> Reply-To: standards-jig at jabber.org
>
> Hi Heiner,
>
>  For a couple of the IQ queries, MU-Conference already acts as a proxy
>  and returns details on behalf of
> the client - iq:last is the main one that comes to mind. If its not a
> proxied query, then the request is  forwarded onto the client. How is
> this different from what you are proposing?
>
> Regards,
>
>  David
>
> On Fri, Dec 05, 2003 at 11:06:07AM +0100, Heiner Wolf wrote:
>> Hi,
>>
>> writing JEP Virtual Presence I reviewed the use of JIDs in chat rooms.
>> I can get rid of JIDs in anonymous rooms, if the room would be able to
>> fetch server storage on behalf of the client. So, clients do not know
>> each other's JID, but get access to each other's server storage
>> through the room.
>>
>> I propose that the room be a proxy, like:
>>   client -> room:
>>   <iq type='get' to='room at server/nickname'>
>>     <query xmlns='storage:client:something'/>
>>   </iq>
>>
>>   room -> server of the client:
>>   <iq type='get' to='user at jid'>
>>     <query xmlns='storage:client:something'/>
>>   </iq>
>>
>>   server of the client -> room:
>>   <iq type='result' to='room at server'>
>>     <query xmlns='storage:client:something'>DATA<query>
>>   </iq>
>>
>>   room -> client:
>>   <iq type='result' to='room at server/nickname'>
>>     <query xmlns='storage:client:something'>DATA<query>
>>   </iq>
>>
>> where only the first stanza is kind of new, but implemented easily.
>>
>> Probably needs configuration if the room is willing to take the
>> traffic load, off by default, etc.
>>
>> hw
>> --
>> Dr. Klaus H. Wolf
>> bluehands GmbH & Co.mmunication KG
>> http://www.bluehands.de/people/hw
>> +49 (0721) 16108 75
>>
>>
>> > -----Original Message-----
>> > From: standards-jig-admin at jabber.org
>> > [mailto:standards-jig-admin at jabber.org]On Behalf Of Peter
>> > Saint-Andre Sent: Friday, December 05, 2003 1:13 AM
>> > To: standards-jig at jabber.org
>> > Subject: [standards-jig] UPDATED: JEP-0045 (Multi-User Chat)
>> >
>> >
>> > At the recent IETF meeting in Minneapolis, I heard one thing that I
>> > through would be useful in MUC: the ability to request voice in a
>> > moderated room without poking any specific room admin. This might be
>> > especially useful in a large room. So I've added a little protocol
>> > for that in JEP-0045. Also I've added a mapping of IRC-style
>> > commands to MUC
>> > protocols for clients that want to implement that.
>> >
>> > http://www.jabber.org/jeps/jep-0045.html
>> >
>> > We really will be done with this soon. Maybe we need to make
>> > it Final so
>> > I stop messing around with it....
>> >
>> > Oh, and I'm not wedded to the voice request protocol, just thought
>> > it would be useful. Let's discuss on the list here.
>> >
>> > Peter
>> >
>> > --
>> > Peter Saint-Andre
>> > Jabber Software Foundation
>> > http://www.jabber.org/people/stpeter.php
>> >
>> > _______________________________________________
>> > Standards-JIG mailing list
>> > Standards-JIG at jabber.org
>> > http://mailman.jabber.org/listinfo/standards-jig
>> >
>> _______________________________________________
>> Standards-JIG mailing list
>> Standards-JIG at jabber.org
>> http://mailman.jabber.org/listinfo/standards-jig
>
> --
> David Sutton
> Email: dsutton at legend.co.uk
> Jabber: peregrine at legend.net.uk
>
> --__--__--
>
> Message: 8
> Subject: RE: [standards-jig] UPDATED: JEP-0045 (Multi-User Chat)
> Date: Fri, 5 Dec 2003 14:44:52 +0100
> From: "Heiner Wolf" <wolf at bluehands.de>
> To: <standards-jig at jabber.org>
> Reply-To: standards-jig at jabber.org
>
> Hi,
>
> great, if it is like that. Is this in JEP-MUC or in the MUC
> documentation?
>
> hw
> --
> Dr. Klaus H. Wolf
> bluehands GmbH & Co.mmunication KG
> http://www.bluehands.de/people/hw
> +49 (0721) 16108 75
>
>
>> -----Original Message-----
>> From: standards-jig-admin at jabber.org
>> [mailto:standards-jig-admin at jabber.org]On Behalf Of David Sutton Sent:
>> Friday, December 05, 2003 2:19 PM
>> To: standards-jig at jabber.org
>> Subject: Re: [standards-jig] UPDATED: JEP-0045 (Multi-User Chat)
>>
>>
>> Hi Heiner,
>>
>>   For a couple of the IQ queries, MU-Conference already acts
>> as a proxy and returns details on behalf of
>> the client - iq:last is the main one that comes to mind. If
>> its not a proxied query, then the request is
>> forwarded onto the client. How is this different from what
>> you are proposing?
>>
>> Regards,
>>
>>   David
>>
>> On Fri, Dec 05, 2003 at 11:06:07AM +0100, Heiner Wolf wrote:
>> > Hi,
>> >
>> > writing JEP Virtual Presence I reviewed the use of JIDs in
>> chat rooms. I
>> > can get rid of JIDs in anonymous rooms, if the room would be able to
>> > fetch server storage on behalf of the client. So, clients
>> do not know
>> > each other's JID, but get access to each other's server
>> storage through
>> > the room.
>> >
>> > I propose that the room be a proxy, like:
>> >   client -> room:
>> >   <iq type='get' to='room at server/nickname'>
>> >     <query xmlns='storage:client:something'/>
>> >   </iq>
>> >
>> >   room -> server of the client:
>> >   <iq type='get' to='user at jid'>
>> >     <query xmlns='storage:client:something'/>
>> >   </iq>
>> >
>> >   server of the client -> room:
>> >   <iq type='result' to='room at server'>
>> >     <query xmlns='storage:client:something'>DATA<query>
>> >   </iq>
>> >
>> >   room -> client:
>> >   <iq type='result' to='room at server/nickname'>
>> >     <query xmlns='storage:client:something'>DATA<query>
>> >   </iq>
>> >
>> > where only the first stanza is kind of new, but implemented easily.
>> >
>> > Probably needs configuration if the room is willing to take
>> the traffic
>> > load, off by default, etc.
>> >
>> > hw
>> > --
>> > Dr. Klaus H. Wolf
>> > bluehands GmbH & Co.mmunication KG
>> > http://www.bluehands.de/people/hw
>> > +49 (0721) 16108 75
>> >
>> >
>> > > -----Original Message-----
>> > > From: standards-jig-admin at jabber.org
>> > > [mailto:standards-jig-admin at jabber.org]On Behalf Of Peter
>> Saint-Andre
>> > > Sent: Friday, December 05, 2003 1:13 AM
>> > > To: standards-jig at jabber.org
>> > > Subject: [standards-jig] UPDATED: JEP-0045 (Multi-User Chat)
>> > >
>> > >
>> > > At the recent IETF meeting in Minneapolis, I heard one
>> thing that I
>> > > through would be useful in MUC: the ability to request voice in a
>> > > moderated room without poking any specific room admin.
>> This might be
>> > > especially useful in a large room. So I've added a little
>> protocol for
>> > > that in JEP-0045. Also I've added a mapping of IRC-style
>> > > commands to MUC
>> > > protocols for clients that want to implement that.
>> > >
>> > > http://www.jabber.org/jeps/jep-0045.html
>> > >
>> > > We really will be done with this soon. Maybe we need to make  it
>> > > Final so
>> > > I stop messing around with it....
>> > >
>> > > Oh, and I'm not wedded to the voice request protocol,
>> just thought it
>> > > would be useful. Let's discuss on the list here.
>> > >
>> > > Peter
>> > >
>> > > --
>> > > Peter Saint-Andre
>> > > Jabber Software Foundation
>> > > http://www.jabber.org/people/stpeter.php
>> > >
>> > > _______________________________________________
>> > > Standards-JIG mailing list
>> > > Standards-JIG at jabber.org
>> > > http://mailman.jabber.org/listinfo/standards-jig
>> > >
>> > _______________________________________________
>> > Standards-JIG mailing list
>> > Standards-JIG at jabber.org
>> > http://mailman.jabber.org/listinfo/standards-jig
>>
>> --
>> David Sutton
>> Email: dsutton at legend.co.uk
>> Jabber: peregrine at legend.net.uk
>> _______________________________________________
>> Standards-JIG mailing list
>> Standards-JIG at jabber.org
>> http://mailman.jabber.org/listinfo/standards-jig
>>
>
>
> --__--__--
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
>
>
> End of Standards-JIG Digest






More information about the Standards mailing list