idnits 2.17.1
draft-rosenberg-peterson-simple-pidf-phone-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 14 instances of too long lines in the document, the longest
one being 8 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (June 23, 2003) is 7613 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: '1' is defined on line 677, but no explicit reference
was found in the text
== Unused Reference: '2' is defined on line 680, but no explicit reference
was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141)
** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '4')
== Outdated reference: A later version (-03) exists of
draft-ietf-simple-data-req-02
== Outdated reference: A later version (-01) exists of
draft-ietf-simple-xcap-auth-usage-00
Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIMPLE J. Rosenberg
3 Internet-Draft dynamicsoft
4 Expires: December 22, 2003 J. Peterson
5 Neustar
6 June 23, 2003
8 Extensions to the Presence Information Document Format (PIDF) for
9 Conveying Phone State
10 draft-rosenberg-peterson-simple-pidf-phone-00
12 Status of this Memo
14 This document is an Internet-Draft and is in full conformance with
15 all provisions of Section 10 of RFC2026.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that other
19 groups may also distribute working documents as Internet-Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at http://
27 www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on December 22, 2003.
34 Copyright Notice
36 Copyright (C) The Internet Society (2003). All Rights Reserved.
38 Abstract
40 This document presents extensions to the Presence Information
41 Document Format (PIDF) for representing the state of telephones. This
42 state includes whether the telephone is in a call or not, whether it
43 is registered to the network, whether it is ringing, and so on.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
48 2. Common State Elements . . . . . . . . . . . . . . . . . . . 3
49 2.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 4
50 3. POTS Line State . . . . . . . . . . . . . . . . . . . . . . 4
51 3.1 POTS line XML Schema . . . . . . . . . . . . . . . . . . . . 6
52 3.2 Example POTS Line PIDF document . . . . . . . . . . . . . . 7
53 4. Enterprise Phone State . . . . . . . . . . . . . . . . . . . 7
54 4.1 Enterprise Phone XML Schema . . . . . . . . . . . . . . . . 7
55 4.2 Enterprise Phone PIDF Document Example . . . . . . . . . . . 9
56 5. Wireless Phone State . . . . . . . . . . . . . . . . . . . . 9
57 5.1 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 11
58 5.2 Example Presence Document . . . . . . . . . . . . . . . . . 12
59 6. Security Considerations . . . . . . . . . . . . . . . . . . 13
60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
61 7.1 URN Sub-Namespace Registrations . . . . . . . . . . . . . . 13
62 7.1.1 urn:ietf:params:xml:ns:pidf:common-phone . . . . . . . . . . 14
63 7.1.2 urn:ietf:params:xml:ns:pidf:wireless-phone-state . . . . . . 14
64 7.1.3 urn:ietf:params:xml:ns:pidf:pls . . . . . . . . . . . . . . 15
65 7.1.4 urn:ietf:params:xml:ns:pidf:eps . . . . . . . . . . . . . . 16
66 7.2 Schema Registrations . . . . . . . . . . . . . . . . . . . . 16
67 7.2.1 Common Phone State . . . . . . . . . . . . . . . . . . . . . 16
68 7.2.2 POTS Line State . . . . . . . . . . . . . . . . . . . . . . 16
69 7.2.3 Enterprise Phone State . . . . . . . . . . . . . . . . . . . 17
70 7.2.4 Wireless Phone State . . . . . . . . . . . . . . . . . . . . 17
71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
72 Normative References . . . . . . . . . . . . . . . . . . . . 17
73 Informative References . . . . . . . . . . . . . . . . . . . 18
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
75 Intellectual Property and Copyright Statements . . . . . . . 20
77 1. Introduction
79 The Presence Information Document Format (PIDF) [6] provides a
80 baseline set of presence information that allows a presentity [7] to
81 inform a watcher about itself. Information about a presentity is
82 broken into a set of tuples. Each tuple represents a point of contact
83 for a presentity. The tuple includes a URI that can be used to reach
84 the presentity, a basic status of either open or closed, and a
85 textual note meant for consumption by a human.
87 PIDF is meant to be extended to provide additional information about
88 presentities. In this specification, we define extensions to PIDF
89 that allow a tuple to represent a telephone, or any device with
90 telephone-like behaviors. Specifically, a telephone is any piece of
91 hardware or software that is capable of making and/or receiving real
92 time media streams with another such device.
94 Most telephones in the world today lack Internet connections, and
95 communicate only through the Public Switched Telephone Network
96 (PSTN). The presence for telephones described in this document might
97 therefore be created by a telephone switch or other agent responsible
98 for managing dumb telephones when the telephones themselves lack the
99 intelligence to generate or disseminate presence information. That
100 much said, these presence extensions are also servicable for
101 representing Internet telephones.
103 2. Common State Elements
105 While the presence states associated with wireless phones, POTS
106 phones and enterprise PBX phones do vary, there are certain pieces of
107 presence state that are common to all. In particular, the notion of
108 call state is common across all three types. As such, we specify a
109 common XML schema for describing call state. The namespace URI for
110 elements that represent common presence state across phones is a URN
111 [3], using the namespace identifier 'ietf' defined by [4] and
112 extended by [5]. This URN is:
114 urn:ietf:params:xml:ns:pidf:common-phone-state
116 The elements defined in this schema are:
118 call-state: This element indicates the state of any calls made by, or
119 received by, the phone. The possible values of this element are:
121 not-in-call: The phone is not in a call.
123 dialing: The phone is attempting to initiate a call. This state
124 includes the entry of digits by the user and the subsequent
125 signaling into the network.
127 ringing: The phone has initiated a call, and has received ringback
128 from the called party.
130 alerting: The phone has received a call, and is alerting the user.
132 in-call: The phone is in an active call.
134 in-error: The call could not be completed because of some kind of
135 error, such as all-circuits-busy.
137 2.1 XML Schema
139
140
See RFCXXXX.
542 543 544 END 546 7.1.2 urn:ietf:params:xml:ns:pidf:wireless-phone-state 548 URI: The URI for this namespace is 549 urn:ietf:params:xml:ns:pidf:wireless-phone-state. 551 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 552 Jonathan Rosenberg (jdrosen@jdrosen.net). 554 XML: 556 BEGIN 557 558 560 561 562 564See RFCXXXX.
570 571 572 END 574 7.1.3 urn:ietf:params:xml:ns:pidf:pls 576 URI: The URI for this namespace is 577 urn:ietf:params:xml:ns:pidf:pls. 579 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 580 Jon Peterson (jon.peterson@neustar.biz). 582 XML: 584 BEGIN 585 586 588 589 590 592See RFCXXXX.
598 599 600 END 602 7.1.4 urn:ietf:params:xml:ns:pidf:eps 604 URI: The URI for this namespace is 605 urn:ietf:params:xml:ns:pidf:eps. 607 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 608 Jon Peterson (jon.peterson@neustar.biz). 610 XML: 612 BEGIN 613 614 616 617 618 620See RFCXXXX.
626 627 628 END 630 7.2 Schema Registrations 632 This specification registers four schemas, as per the guidelines in 633 in [5]. 635 7.2.1 Common Phone State 637 URI: please assign. 639 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 640 Jon Peterson (jon.peterson@neustar.biz). 642 XML: The XML can be found as the sole content of Section 2.1. 644 7.2.2 POTS Line State 645 URI: please assign. 647 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 648 Jon Peterson (jon.peterson@neustar.biz). 650 XML: The XML can be found as the sole content of Section 3.1. 652 7.2.3 Enterprise Phone State 654 URI: please assign. 656 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 657 Jon Peterson (jon.peterson@neustar.biz). 659 XML: The XML can be found as the sole content of Section 4.1. 661 7.2.4 Wireless Phone State 663 URI: please assign. 665 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 666 Jonathan Rosenberg (jdrosen@jdrosen.net). 668 XML: The XML can be found as the sole content of Section 5.1. 670 8. Acknowledgments 672 The authors would like to thank Rob Allen, Adam Roach and Mark Peck 673 for their comments on this specification. 675 Normative References 677 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 678 Levels", BCP 14, RFC 2119, March 1997. 680 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 681 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC 682 REC-xml-20001006, October 2000. 684 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 686 [4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 687 August 1999. 689 [5] Mealling, M., "The IETF XML Registry", 690 draft-mealling-iana-xmlns-registry-05 (work in progress), June 691 2003. 693 [6] Fujimoto, S. and H. Sugano, "Presence Information Data Format 694 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 695 2003. 697 Informative References 699 [7] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 700 Instant Messaging", RFC 2778, February 2000. 702 [8] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of 703 Data Elements in Session Initiation Protocol (SIP) for Instant 704 Messaging and Presence Leveraging Extensions (SIMPLE) Systems", 705 draft-ietf-simple-data-req-02 (work in progress), April 2003. 707 [9] Rosenberg, J., "A Presence Event Package for the Session 708 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 709 in progress), January 2003. 711 [10] Rosenberg, J., "The Extensible Markup Language (XML) 712 Configuration Access Protocol (XCAP)", 713 draft-rosenberg-simple-xcap-00 (work in progress), May 2003. 715 [11] Rosenberg, J., "An Extensible Markup Language (XML) 716 Configuration Access Protocol (XCAP) Usage for Presence 717 Authorization", draft-ietf-simple-xcap-auth-usage-00 (work in 718 progress), June 2003. 720 Authors' Addresses 722 Jonathan Rosenberg 723 dynamicsoft 724 600 Lanidex Plaza 725 Parsippany, NJ 07054 726 US 728 Phone: +1 973 952-5000 729 EMail: jdrosen@dynamicsoft.com 730 URI: http://www.jdrosen.net 731 Jon Peterson 732 Neustar 733 1800 Sutter Street 734 Suite 570 735 Concord, CA 94520 736 US 738 Phone: +1 925 363-8720 739 EMail: jon.peterson@neustar.biz 740 URI: http://www.neustar.biz 742 Intellectual Property Statement 744 The IETF takes no position regarding the validity or scope of any 745 intellectual property or other rights that might be claimed to 746 pertain to the implementation or use of the technology described in 747 this document or the extent to which any license under such rights 748 might or might not be available; neither does it represent that it 749 has made any effort to identify any such rights. Information on the 750 IETF's procedures with respect to rights in standards-track and 751 standards-related documentation can be found in BCP-11. Copies of 752 claims of rights made available for publication and any assurances of 753 licenses to be made available, or the result of an attempt made to 754 obtain a general license or permission for the use of such 755 proprietary rights by implementors or users of this specification can 756 be obtained from the IETF Secretariat. 758 The IETF invites any interested party to bring to its attention any 759 copyrights, patents or patent applications, or other proprietary 760 rights which may cover technology that may be required to practice 761 this standard. Please address the information to the IETF Executive 762 Director. 764 Full Copyright Statement 766 Copyright (C) The Internet Society (2003). All Rights Reserved. 768 This document and translations of it may be copied and furnished to 769 others, and derivative works that comment on or otherwise explain it 770 or assist in its implementation may be prepared, copied, published 771 and distributed, in whole or in part, without restriction of any 772 kind, provided that the above copyright notice and this paragraph are 773 included on all such copies and derivative works. However, this 774 document itself may not be modified in any way, such as by removing 775 the copyright notice or references to the Internet Society or other 776 Internet organizations, except as needed for the purpose of 777 developing Internet standards in which case the procedures for 778 copyrights defined in the Internet Standards process must be 779 followed, or as required to translate it into languages other than 780 English. 782 The limited permissions granted above are perpetual and will not be 783 revoked by the Internet Society or its successors or assignees. 785 This document and the information contained herein is provided on an 786 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 787 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 788 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 789 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 790 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Acknowledgement 794 Funding for the RFC Editor function is currently provided by the 795 Internet Society.