?? x6079.htm
字號:
<offline/>
<id>M31</id>
</x>
</message></PRE
></P
><P
>That is, the <TT
CLASS="LITERAL"
><offline/></TT
> tag is sent back
to the originator, along with an <TT
CLASS="LITERAL"
><id/></TT
> tag
which contains the <TT
CLASS="LITERAL"
>id</TT
> of the message that was stored
offline.</P
><P
><A
HREF="x6079.htm#JABTDG-CH-5A-EX-10"
>Example 5a-5</A
> shows the receipt of a chat message
and the <TT
CLASS="LITERAL"
><composing/></TT
> event being raised
as Sabine starts to type her reply.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-5A-EX-10"
></A
><P
><B
>Example 5a-5. Raising and cancelling the <TT
CLASS="LITERAL"
><composing/></TT
> evevent</B
></P
><P
>DJ sends a quick chat message to Sabine, and requests that his client
be notified when she starts typing her response.</P
><P
><PRE
CLASS="SCREEN"
>RECV: <message to='sabine@yak/Work' from='dj@yak/home' id='122' type='chat'>
<body>hey, want a coffee?</body>
<thread>ABAF6FC6521546A2B65B19EA391CB72A</thread>
<x xmlns='jabber:x:event'>
<composing/>
</x>
</message></PRE
></P
><P
>Sabine starts to type, which fires the
<TT
CLASS="LITERAL"
><composing/></TT
> event:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <message from='sabine@yak/Work' to='dj@yak/home'>
<x xmlns='jabber:x:event'>
<composing/>
<id>122</id>
</x>
</message></PRE
></P
><P
>Sabine is distracted, and her client decides she's abandoned the reply,
and sends a cancellation of the
<TT
CLASS="LITERAL"
><composing/></TT
> event, containing only the
message <TT
CLASS="LITERAL"
>id</TT
> included when the event was originally raised.</P
><P
><PRE
CLASS="SCREEN"
>SEND: <message from='sabine@yak/Work' to='dj@yak/home'>
<x xmlns='jabber:x:event'>
<id>122</id>
</x>
</message></PRE
></P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5A-SECT-3.7"
><TT
CLASS="LITERAL"
>jabber:x:expire</TT
></A
></H2
><P
>The <TT
CLASS="LITERAL"
>jabber:x:expire</TT
> is a simple namespace to
add an 'use by' or 'read by' stamp to a message. If you wish to send a
message impose a finite lifetime upon it, attach an expiry extension thus:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <message to='piers@pipetree.com' id='M24'>
<subject>Eccles cakes!</subject>
<body>
I've got some fresh Eccles cakes here, pop
round for one before they all disappear!
</body>
<x xmlns='jabber:x:expire' seconds='1800'/>
</message></PRE
></P
><P
>If John was not connected when the message was sent, the
<TT
CLASS="LITERAL"
>mod_offline</TT
> module would hold the message ready
for when he reconnects. But before storing it, an extra attribute (<TT
CLASS="LITERAL"
>stored</TT
>) is added with the current
time. <A
HREF="x6079.htm#JABTDG-CH-5A-EX-11"
>Example 5a-6</A
> shows what the relevant section
of John's spool file would look like.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-5A-EX-11"
></A
><P
><B
>Example 5a-6. Storage of an offline message with the <TT
CLASS="LITERAL"
>jabber:x:expire</TT
> extension</B
></P
><P
><PRE
CLASS="SCREEN"
><foo xmlns='jabber:x:offline' xdbns='jabber:x:offline'>
<message to='piers@pipetree.com' id='M24' from='dj@pipetree.com/kitchen'>
<subject>Eccles cakes!</subject>
<body>
I've got some fresh Eccles cakes here, pop
round for one before they all disappear!
</body>
<TT
CLASS="USERINPUT"
><B
><x xmlns='jabber:x:expire' seconds='600' stored='993038415'/></B
></TT
>
<x xmlns='jabber:x:delay' from='dj@pipetree.com' stamp='20010620T12:00:15'>
Offline Storage
</x>
</message>
</foo></PRE
></P
></DIV
><P
>When John reconnects, <TT
CLASS="LITERAL"
>mod_offline</TT
> retrieves the message
and compares the current time with the value in the
<TT
CLASS="LITERAL"
>stored</TT
> attribute. If the difference exceeds the
desired lifetime of the message, as specified in the
<TT
CLASS="LITERAL"
>seconds</TT
> attribute, the message is discarded. Otherwise,
the <TT
CLASS="LITERAL"
>seconds</TT
> attribute value is reduced to reflect the
amount of time the message sat in storage, the <TT
CLASS="LITERAL"
>stored</TT
>
attribute is removed, and the message is sent to John.</P
><P
>Furthermore, if John's client supports it, a further check of the message's
lifetime can be made before display, in case the message was stored in an
inbox-style mechanism.
(With John's luck, he probably missed out on the Eccles cake.)</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5A-SECT-3.8"
><TT
CLASS="LITERAL"
>jabber:x:oob</TT
></A
></H2
><P
>We've already seen the <TT
CLASS="LITERAL"
>jabber:x:oob</TT
> in action earlier
in the book. It is used in a similar way to its big brother the
<TT
CLASS="LITERAL"
>jabber:iq:oob</TT
> namespace. Attaching URLs to messages,
typically done by mechanisms that delivery news and alert style headines,
is done like this:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <message type='headline' to='qmacro@jabber.org/laptop' id='h12'>
<subject>Jabber Foundation Public Conference</subject>
<x xmlns='jabber:x:oob'>
<url>
http://www.jabbercentral.com/news/view.php?news_id=989358658
</url>
<desc>
Tomorrow, May 9th, a meeting regarding the Jabber
Foundation will be held.
</desc>
</x>
</message></PRE
></P
><P
>Multiple attachments can be made to a message.</P
><P
>The RSS Punter, described in <A
HREF="x9016.htm"
>the section called <I
>RSS punter</I
> in Chapter 8</A
> and the
Headline Viewer, described in <A
HREF="x9991.htm"
>the section called <I
>Headline viewer</I
> in Chapter 8</A
> both
use the <TT
CLASS="LITERAL"
>jabber:x:oob</TT
> namespace.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5A-SECT-3.9"
><TT
CLASS="LITERAL"
>jabber:x:roster</TT
></A
></H2
><P
>The <TT
CLASS="LITERAL"
>jabber:x:roster</TT
> namespace is related to its big
brother <TT
CLASS="LITERAL"
>jabber:iq:roster</TT
>; it is used to carry
roster information as message attachments. This makes it straightforward
for users to exchange contact information between themselves:</P
><P
><PRE
CLASS="SCREEN"
>SEND: <message id='M91' to='shiels@jabber.org'>
<body>Hi Robert - this is that fool I was telling you about...</body>
<x xmlns='jabber:x:roster'>
<item jid='qmacro@jabber.org' name='DJ Adams'>
<group>Fools</group>
</item>
</x>
</message></PRE
></P
><P
>Note that it is inappropriate to send the subscription related attributes
(<TT
CLASS="LITERAL"
>subscription</TT
> and <TT
CLASS="LITERAL"
>ask</TT
>, described
in <A
HREF="x5334.htm#JABTDG-CH-5A-SECT-2.12"
>the section called <I
><TT
CLASS="LITERAL"
>jabber:iq:roster</TT
></I
></A
>). Instead, it is up
to the recipient to negotiate their own presence subscription arrangements
with the contact, or contacts (more than one item can be sent in such an
attachment) listed.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5A-SECT-3.10"
><TT
CLASS="LITERAL"
>jabber:x:signed</TT
></A
></H2
><P
>The <TT
CLASS="LITERAL"
>jabber:x:signed</TT
> namespace is related to the
<TT
CLASS="LITERAL"
>jabber:x:encrypted</TT
> namespace and is used to
stamp <TT
CLASS="LITERAL"
><presence/></TT
> and
<TT
CLASS="LITERAL"
><message/></TT
> packets with a PKI-based
signature, thus providing reliable identification of the packet
originator.</P
><P
>In generating the signature block, some relevant data must be used
to pass into the signing algorithm so that an electronic signature
is produced.
<A
NAME="AEN6284"
HREF="#FTN.AEN6284"
>[2]</A
>
In the case of <TT
CLASS="LITERAL"
><presence/></TT
> packets, the
contents of the <TT
CLASS="LITERAL"
><status/></TT
> tag are
used, and in the case of <TT
CLASS="LITERAL"
><message/></TT
>
packets, the contents of the <TT
CLASS="LITERAL"
><body/></TT
>
tag are used.</P
><P
>The presence of a <TT
CLASS="LITERAL"
>jabber:x:signed</TT
> signature in a
<TT
CLASS="LITERAL"
><presence/></TT
> packet is intended to
signify that the client sending the packet supports such PKI
infrastucture and, for example, is able to decrypt messages encrypted
in the <TT
CLASS="LITERAL"
>jabber:x:encrypted</TT
> namespace.</P
><P
>Here's a <TT
CLASS="LITERAL"
><presence/></TT
> packet containing
a signature; the data <I
CLASS="EMPHASIS"
>All present and correct</I
> is what
is fed into the algorithm.</P
><P
><PRE
CLASS="SCREEN"
>SEND: <presence from='piers@jabber.org' to='qmacro@pipetree.com'>
<status>All present and correct</status>
<x xmlns='jabber:x:signed'>
aslkjlksjdf jsfkjk23jskdfskjdfksjdf
</x>
</presence></PRE
></P
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN6140"
HREF="x6079.htm#AEN6140"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The filter service is described in
<A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.1.3.1"
>the section called <I
>Filter Service</I
> in Chapter 4</A
>.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.AEN6284"
HREF="x6079.htm#AEN6284"
>[2]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>Typically, when signing an email message electronically, the body
of the email is passed into the signing algorithm to generate the
signature.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x5334.htm"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.htm"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x6299.htm"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>The IQ Namespaces</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="c5281.htm"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>The X::IQ relationship</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -