summaryrefslogtreecommitdiff
path: root/spec/Channel_Interface_HTML.xml
blob: ad86867caf3aee6da55dbe981fab36156d6f2db9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
<?xml version="1.0" ?>
<node name="/Channel_Interface_HTML"
  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
  <tp:copyright>Copyright (C) 2008 Collabora Ltd.</tp:copyright>
  <tp:copyright>Copyright (C) 2008 Nokia Corporation</tp:copyright>
  <tp:license xmlns="http://www.w3.org/1999/xhtml">
    <p>This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.</p>

<p>This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Lesser General Public License for more details.</p>

<p>You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
  </tp:license>
  <interface
    name="org.freedesktop.Telepathy.Channel.Interface.HTML.DRAFT"
    tp:causes-havoc="unfinished">
    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Text"/>
    <tp:requires
      interface="org.freedesktop.Telepathy.Channel.Interface.Messages"/>
    <tp:added version="0.17.5">(draft version, not API-stable)</tp:added>

    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
      <p>This interface extends the Messages interface to support
        capability discovery, so clients can decide what subset of HTML
        is supported.</p>

      <p>(However, the capability discovery mechanism has not been written
        yet, so this interface MUST NOT be used. It exists only to
        indicate what direction we intend to go in.)</p>

      <tp:rationale>
        <p>XMPP supports all of XHTML-IM, and SIP (at least theoretically)
          supports all of XHTML. However, many protocols are more limited -
          for instance, in MSN you can only set font properties for a
          whole message at a time. We should not mislead users into thinking
          they can send MSN messages where individual words are emphasized.</p>
      </tp:rationale>

      <p>If this interface is present, clients MAY send XHTML formatted text
        in message parts with type "text/html", and SHOULD interpret
        "text/html" message parts received in reply.</p>

      <p>Client authors SHOULD pay careful attention to the security
        considerations in XEP-0071, "XHTML-IM", to avoid exposing client users
        to security risks. Clients MUST NOT assume that connection managers
        will filter messages to remove unsafe HTML.</p>

      <tp:rationale>
        <p>Connection managers are the components in Telepathy that are most
          likely to be exploitable by a remote attacker to run malicious code
          (since they are network-facing), so any filtering that the CM does
          might be subverted.</p>
      </tp:rationale>

      <p>To avoid misleading users, clients SHOULD only present UI for the
        subset of HTML that is indicated to be supported by this
        interface. It follows that clients SHOULD NOT send unsupported
        markup to the connection manager. However, even if the connection
        manager cannot send arbitrary XHTML, it MUST cope gracefully
        with being given arbitrary XHTML by a client.</p>

      <tp:rationale>
        <p>Connection managers should be lenient in what they receive.</p>
      </tp:rationale>

      <p>Clients MUST NOT send HTML that is not well-formed XML, but
        connection managers MAY signal HTML that is malformed or invalid.
        Clients SHOULD attempt to parse messages as XHTML, but fall back
        to using a permissive "tag-soup" HTML parser if that fails.
        (FIXME: or should the presence of this interface imply that the
        CM fixes up "text/html" to be XHTML? In practice that would result
        in all the CMs having to link against libxml2 or something... the
        rationale above no longer applies here, since dropping a malformed
        message is "safe")</p>
    </tp:docstring>

  </interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->