On 06/16/2008 4:06 PM, Michael Laukner wrote:
> Thanks for the quick reply.
We AIM to please!
> On Mon, Jun 16, 2008 at 5:58 PM, Peter Saint-Andre <stpeter (AT) stpeter (DOT) im> wrote:
>> On 06/14/2008 11:09 AM, Michael Laukner wrote:
>>> Peter,
>>> We may not underestimate the importance of logging when talking about
>>> the use of XMPP in an enterprise environment. Being able to have
>>> logging of chat conversation is one of the biggest advantages of MUC
>>> (besides the security features). Most of our rooms persist and room
>>> names never change. The log is treated like meeting minutes, published
>>> and stored in an archive.
>> Oh yes, I know -- we do that for some rooms at conference.jabber.org.
>> And some organizations even require such logging for compliance purposes
>> (SEC / HIPAA, etc.).
>
> Yes, Jabber log is a good example
> http://logs.jabber.org/jabber (AT) conference (DOT) jabber.org/ Since all
> the logs are stored daily, they run from 00:00 to 23:59
>
> Let's say the sales team meets every day from 08:00 to 09:00.
>
> If they would use the jabber-log logic, the first joiners will be
> bothered with history messages that wer send between 00:00 to 08:00
> (if the server script did a clean-up of the logs), or even with
> history messages from a previous meeting.
The messages sent between 00:00 and 08:00 might be germane, because
typically some people join the room before 08:00 and chat a bit before
the meeting. If a room admin wants to clear that history so that new
people who join after 08:00 will never see the pre-08:00 messages, then
we'd need a clear-history command of some kind, but I see no particular
reason to auto-clear that history unless a server product really sees
the need for that (e.g., only messages sent during the official meeting
time are part of the history -- not to be confused with "part of the
room log").
Please note that history is different from log. The log is a permanent
archive, typically written to disk or a database. The history is held in
temporary memory and is sent to a participant when they join the room
(typically the last 20 messages or whatever). You can receive history in
a room that is not logged, and you can log a conversation from a room
where no history is sent on joining the chatroom.
> Use case #2: Web Conferencing (see
> http://www.jabber.com/JabberXCPAdobeAcrobatConnect2/benefits.html )
> Use case #3: Support - Group Chat on
> http://www.igniterealtime.org/support/group_chat.jsp
>
> Meeting is set for every Wednesday at 10:00 AM PST (17:00 UTC/GMT)
> for one hour. The conversation transcipt shows:
> Participants: xx
> Start Date: mm dd, yyyy hh:mm:ss AM
> Duration: hh h, mm min
> Message Count: xxx
See above. Permanent log or transcript != temporary history.
> Use case #4: RDF log is another example which we may leave out for now.
> http://danbri.org/words/category/jabberxmpp
>
>>> I agree with Boyd, the current version of XEP-45 considers logging
>>> (7.1.14 Room Logging) from a user's privacy perspective but not as an
>>> enterprise conferencing feature.
>> Typically it is considered as an enterprise conferencing feature by
>> people who sell commercial XMPP servers, and by people who administer
>> certain kinds of MUC services. And I'm one of the latter.
>>> We have the same problem; currently we are doing it outside XMPP
>>> (using direct SQL statements to backup and archive logs) because
>>> nothing seem to exist in
>>> XEP-0045: Multi-User Chat
>>> XEP-0241: Encryption of Archived Messages
>>> XEP-0136: Message Archiving
>> What features do people need here? And who are the actors?
>
> I think the logging features should apply to room owners, moderators
> and/or administrators.
Currently, room admins and owners can enable or disable logging as a
room configuration option, but cannot do more sophisticated things like
editing the logs (someone says something that needs to be removed from
the permanent archive), delete logs once they are written to disk or
database, etc. At least that's how ejabberd and mu-conference handle
things -- perhaps other implementations are more sophisticated.
>> Right now,
>> XEP-0045 addresses uses cases for end users and room admins, but not
>> service admins. I could see the following use cases for MUC service
>> admins in relation to logs:
>>
>
> 1. Edit log
> 2. Delete log
We don't have those now.
> 3. Disable logging
This can be done via room configuration.
> 4. Start logging (and inform users/joiners)
> 5. Stop logging (and inform users/joiners)
This can be done by changing the room configuration whenever you want to
start (enable) or stop (disable) logging.
> 6. Archive log (and clean history)
I'm not sure what this means.
> 7. Restore log (??? not sure about this)
I think that's something you (as a room admin or owner) would ask a
service-wide admin to do.
>> The clear room history feature doesn't really have an impact on logging
>> (it just clears the in-memory cache of what's shown to people who join
>> the room).
>
> Some XMPP servers store it in the database (where it could live forever).
Correct.
> On the other hand 7.1.16 Managing Discussion History already exist
That is a use case for asking the server how much history your client
wants to receive.
> We could add another example e.g.
>
> Example 38. Room Admin Requests Clear History
>
> <presence
> from='hag66 (AT) shakespeare (DOT) lit/pda'
> to='darkcave (AT) macbeth (DOT) shakespeare.lit/thirdwitch'>
> <x xmlns='http://jabber.org/protocol/muc'>
> <history maxchars='-1'/>
> </x>
> </presence>
And what would happen as a result? I think there is some confusion on
what we mean by "clear room history".
>> So perhaps it's something that a room admin does, not
>> something that a service admin does.
>
> Yes, room admin may send room config and trigger enable/disable public logging:
>
> <field var='muc#roomconfig_enablelogging'>
> <value>0</value>
> </field>
>
> The room service may add the URL for discussion logs in the room info:
>
> <field var='muc#roominfo_logs' label='URL for discussion logs'>
> <value>http://www.shakespeare.lit/chatlogs/darkcave/</value>
> </field>
Right, we already have that stuff.
Peter
--
Peter Saint-Andre
https://stpeter.im/