Internet DRAFT - draft-howard-simple-offline-status
draft-howard-simple-offline-status
Simple Working Group Hao Wang
Internet-Draft Qian Sun
Intended status: Informational Huawei Technologies
Expires: December 25, 2007 June 27, 2007
A Clarification for Offline Status Assigned by Presence Application
draft-howard-simple-offline-status-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 25, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
'Offline' status assigned by presence application usually mean
that the presence application will expect his watcher thinks
he is not online, though he may actually be online. According
current specifications of presence service, the watcher may
have a way to find out some clues to identify the truth. Such
leak of specifications will make confusion in implementation.
Here try to state a clarification for thus issue.
1. Introduction
Session Initiation Protocol (SIP) Extension for Event State
Publication [RFC3903] allows Presence User Agents ('PUA') to
publish presence information of a user ('presentity'). The
Howard Expires December 27, 2007 [Page 1]
Internet-Draft offline in Presence June 2007
Presence Agent ('PA') collects publication information from
one or several PUA, generates the composite event state of the
presentity; and allow other user ('watcher') to subscribe to the
presentity in order to learn his presence information. The
presentity can use a mean, named as Notifier, to delivery his
own presence information to other watchers who had subscribed.
On other hand the presentity can also use a mean, named as
Fetcher, to get presence information of his watcher, whom
had subscribed already.
Presence publication by default uses the PIDF document format,
and each publication contains full state regardless of how
much of the presence information has actually changed since the
previous update.
In fact while a presentity want to hide him invisible as 'off
line' status though he is actually online, he can assign with
'offline' status to stop his Notifier to delivery off 'online'
information to those watchers who had subscribed, then his user
name will not appear in his watchers' 'online' page. However, his
Fetcher may still fetch the presence information of his watchers,
usually symmetrical presentity is also a subscriber of presence
information of his watcher. In such situation, the watcher can
identify that the presentity is still online instead of his
appearance 'offline'. It is indeterminacy in presence service
specifications and will cause leak in implementation.
Although this document is an analysis document and not a BCP
document, a possible optimizations is listed in addition to an
initial set of requirements for what should be the characteristic
of the solution to the problem stated in the document
This document is intended to be used by the SIMPLE WG in order to
work on possible solutions that will make the deployment of a
presence server more reasonable task. Note that the document does
not try to compare the SIP based presence server to other types of
presence servers but only analyses the SIP based presence server.
This memo tries to clarify this leak and is structured in such a
way: Section 3 gives an overview of the indeterminacy on 'off-line'
for presence implements; Section 4 includes proposed detailed
solution; Section 5 includes discussion of security considerations;
and Section 6 includes examples of publication for assign 'off-line'.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119, and
indicate requirement levels for compliant implementations.
Howard Expires December 27, 2007 [Page 2]
Internet-Draft offline in Presence June 2007
This document makes use of the vocabulary defined in the Model
for Presence and Instant Messaging [RFC2778], and the Event State
Publication Extension to SIP [RFC3903].
3. Overview of the indeterminacy on 'off-line' status
Although current specifications had defined some rules to composite
with tuples in the document of presence service, it still omit the
clues for 'offline' status.
Further regard to thus 'offline' status, it may cause consequence
arising in IOP & relevant for IMS; and make special meaning when
the presentity try to subscribe status of himself.
3.1 Clarification for 'offline' vs. 'unknown'
Presentity can usually be in such a status 'unknown' or 'offline'
beyond in 'online' status, but 'offline' status is not as same as
'unknown' status.
The status 'unknown' would apply if a Notifier or a Watcher is not
able to gather consistent presence information about the presentity.
It usually happen when the presentity lost communication between
his PUA and PA, then the PA does not have any consistent published
information from PUA to composite a valid event state of the
presentity.
The status 'offline' would apply when the Notifier got information
that the Presentity is actually 'offline' or unavailable (<status>
<basic> closed </basic> </status> in PIDF terms). Among 'offline'
status of a presentity, the appearance, shown as 'offline' but the
presentity is actually reachable, can be achieved by publishing
presence information with status tuples marked as 'closed', while
the actual communication with the service is not dropped down.
3.2 Communication approach
The fact, a PA publishes its PUA availability as 'closed' status,
may not necessarily mean that the presentity is actually unreachable
for that application. The dialog maintained between a presence
source and Presence Server ('PS') is independent from the
communications that are actually maintained between any other SIP
applications residing in a client device and the corresponding
application server that hosts that application.
Additionally, the communication that a Presence Source establishes
with a PS is independent of the SIP subscription that a Watcher
(possibly co-located with the Presence Source) establishes to
receive Presence information about other contacts (i.e.: nothing
would prevent publishing one s status as 'offline', while still
Howard Expires December 27, 2007 [Page 3]
Internet-Draft Offline in Presence June 2007
receiving Presence information about his contacts).
3.3. Behavior of presentity under 'offline' status
While presentity has published as 'offline' status, its Notifier
will stop in general to deliver presence information to his watchers,
who had subscribed, since last time the presentity published for
'offline' status. The watcher will keep up the status of the
presentity as 'offline' status published in last time till updated
by the presentity in next time.
But because the presentity is still keep communication alive in fact,
his Fetcher can take behaviors in different way to request or not
for presence information of his watchers. It depended on the
implementation in detail and there is none relevant clarifications
in current request specifications. It will cause ambiguity for users
communicating from different implementations of presence service.
3.3.1 Implementation 1 --- Fetcher stop
After the PUA generated a complete 'offline' PIDF file of presence
information of a presentity and PUBLISH the file to presence service
as his presence scheme, his Fetcher can stop request of collecting
other watcher's presence information.
Then the watcher or its PA will not receive request from PA of the
presentity and need not responds with such requests, just like the
presentity has dropped down communication from presence service.
The watcher can deduct out only one conclusion that the presentity
is real offline?
3.3.2 Implementation 2 --- Fetcher alive
After the PUA of presentity PUBLISH to presence service as 'offline'
status, his Fetcher may keep on requesting to collect other watcher's
presence information; especially some pollers sent such request on
a regular basis.
Then the watcher or its PA will receive such request from PA of the
presentity and has to responds with watcher's presence information,
just like the presentity has not published for 'offline' status.
Then the watcher may have two deductions on status of the presentity
depend on different implementations:
1) The watcher does responds for any requests about its presence
information and not care whom the request come from. Thus the watcher
knows about the status just as 'offline' status as published by the
original presentity.
2) The watcher check about published status of a presentity, who is
Howard Expires December 27, 2007 [Page 4]
Internet-Draft offline in Presence June 2007
requesting for presence information, and found originally published
status as 'offline' status, then watcher will realize that this
presentity is only appeared as 'offline' status and reachable in
fact.
For showing in easiest way, here gives an extremely case for above
issue --- one presentity has subscribed own presence status and try
to assign as 'offline' status, he will meet such a puzzle --- he
can always find he is active in 'online' status, although he has
assigned himself as 'offline' already.
It is out of scope of this document what consequence will happen
when the watcher found the truth. But it definitely is opposite to
the assumption of original presentity.
3.3.3 Rely on 'note'
In some case, it can use the 'note' element to mark functionally
update of presence status in presence document.
Relying on the 'note' element is not a proper way to ensure that
implementations will interoperate smoothly. <note> is supposed to
be understood by humans, so Notifier is not supposed to process it.
In fact, RFC 2778 discourages its usage to substitute the status
of its parent element.
3.4 Issue arise in IOP
According above 3.3.2, there should be some confusion for presentity
of presence service that use implementations with different presence
principle. Then it should bring up an IOP issue in presence service.
3.5 IMS relevant
Above discussion is in scope of presence specifications in SIMPLE
group, it may be different in IMS relevant, which may be wise /
feasible to overrule the IMS registration status in 3GPP SIP
deployments (i.e.: it seems difficult to publish an "IMS
unregistered" status, and still try to be registered to the IMS).
4. Proposed solution
Here try to propose a simple way as solution for this issue, though
it may not be a full complete solution.
If the PA of presentity does Fetcher to a watcher, usually implement
by 'SUBSCRIBE', with a 'filter' condition to indicate PS update the
watcher exclude the fact --- which the Fetcher is inquiring about
presence status of the watchers. And PS will follow the indication
not to notice the watcher about the inquiry, although PS will notice
Howard Expires December 27, 2007 [Page 5]
Internet-Draft offline in Presence June 2007
the watcher by default in general.
Then above ambiguities issue will become a single case of presence
status.
Fetcher PA PS Watcher PA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK | |
|<------------------| |
| | Update presence |
| |------------------------>|
| | exclude the 'subscribe' |
Message Details
F1 SUBSCRIBE Fetcher PA->example.com server
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/TCP fetcherhost.example.com;branch=z9hG4bKnashds7
To: <sip:resource@example.com>
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@fetcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml
Contact: <sip:user@fetcherhost.example.com>
Expires: 600
Content-Length: 0
F2 200 OK example.com server->Fetcher PA
SIP/2.0 200 OK
Via: SIP/2.0/TCP fetcherhost.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
To: <sip:resource@example.com>;tag=ffd2
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@fetcherhost.example.com
CSeq: 17766 SUBSCRIBE
Contact: sip:server.example.com
Expires: 600
Content-Length: 0
5. Security considerations
Whatever this solution could be considered as BCP, it would be seen
as a potential way of accomplishing the requested goal. Usually the
presentity subscribes also symmetrically to his watcher, any his
inquiries is with authority by the watcher, then it won't override
Howard Expires December 27, 2007 [Page 6]
Internet-Draft offline in Presence June 2007
the rule of PS whether the Fetcher indicates PS not update with
watcher.
6. Appendix A. Acknowledgments
This document is based on discussions within the IETF SIMPLE working
group. Krisztian Kiss, Peili Xu provided helpful input.
7. References
7.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP)
Extension for Event State Publication", RFC 3903,
October 2004.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A.,
Carr, W., and J. Peterson, "Presence Information Data
Format (PIDF)", RFC 3863, August 2004.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
7.2. Informative references
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February
2000.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)", RFC 4480,
July 2006.
[RFC4481] Schulzrinne, H., "Timed Presence Extensions to the
Presence Information Data Format (PIDF) to Indicate
Status Information for Past and Future Time
Intervals", RFC 4481, July 2006.
[RFC4482] Schulzrinne, H., "CIPID: Contact Information for the
Presence Information Data Format", RFC 4482, July
2006.
Howard Expires December 27, 2007 [Page 7]
Internet-Draft offline in Presence June 2007
8. IANA Considerations
This document does not request any IANA actions.
9. Author's Addresses
Hao Wang
Huawei Technologies Co.,Ltd.
Huawei Base, Bantian
Shenzhen, P.R. of China, 518129
Phone: +86 755 2878 0808
Email: howard.wang@huawei.com
Qian Sun
Huawei Technologies Co., Ltd.
Huawei Base, Bantian
Shenzhen, P.R China, 518129
Phone: +86 755 28780808
Email: sunqian@huawei.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
Howard Expires December 27, 2007 [Page 8]
Internet-Draft offline in Presence June 2007
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
