Network Working Group                                        A. Melnikov
Internet-Draft                                             Isode Limited
Intended status: Standards Track                          H. Schulzrinne
Expires: August 20, 2008                                     Columbia U.
                                                                  Q. Sun
                                                     Huawei Technologies
                                                       February 17, 2008


               Sieve Notification Mechanism: SIP MESSAGE
               draft-melnikov-sieve-notify-sip-message-01

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 August 20, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent over the SIP
   MESSAGE.





Melnikov, et al.         Expires August 20, 2008                [Page 1]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.    Definition . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1.  Notify parameter "method"  . . . . . . . . . . . . . . . . .  3
   2.2.  Notify tag ":from" . . . . . . . . . . . . . . . . . . . . .  3
   2.3.  Notify tag ":options"  . . . . . . . . . . . . . . . . . . .  3
   2.4.  Notify tag ":importance" . . . . . . . . . . . . . . . . . .  4
   2.5.  Notify tag ":message"  . . . . . . . . . . . . . . . . . . .  4
   2.6.  Other Definitions  . . . . . . . . . . . . . . . . . . . . .  4
   2.7.  Test notify_method_capability  . . . . . . . . . . . . . . .  4

   3.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  5

   4.    Requirements Conformance . . . . . . . . . . . . . . . . . .  6

   5.    Security Considerations  . . . . . . . . . . . . . . . . . .  7

   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7

   7.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  7

   8.    Normative References . . . . . . . . . . . . . . . . . . . .  8

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  8
         Intellectual Property and Copyright Statements . . . . . . . 10















Melnikov, et al.         Expires August 20, 2008                [Page 2]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


1.  Introduction

1.1.  Overview

   The NOTIFY [NOTIFY] extension to the SIEVE [SIEVE] mail filtering
   language is a framework for providing notifications by employing URIs
   to specify the notification mechanism.  This document defines how SIP
   URIs (see RFC 3261 [SIP]) are used to generate notifications via the
   SIP MESSAGE (see RFC 3428 [RFC3428]).

1.2.  Terminology

   This document inherits terminology from NOTIFY [NOTIFY], SIEVE
   [SIEVE], and RFC 3261 [SIP].


2.  Definition

   The sip message mechanism results in the sending of a SIP MESSAGE
   request to notify a recipient about an email message.

2.1.  Notify parameter "method"

   The "method" parameter MUST be a URI that conforms to the SIP (or
   SIPS) URI scheme (as specified in RFC 3261 [SIP]) and that identifies
   a SIP (or SIPS) recipient of the notification.  The URI MAY include
   the resource identifier portion of a SIP address and URI parameters.
   The URI parameter "method" MUST be ignored, because only the MESSAGE
   method is allowed by this specification.  The processing application
   MUST extract a SIP address from the URI in accordance with the
   processing rules specified in RFC 3261 [SIP].  The resulting SIP
   address MUST be encapsulated in SIP URI syntax as Request-URI and the
   value of the "To" header field of the SIP MESSAGE request.

2.2.  Notify tag ":from"

   The value of the ":from" tag MUST use the SIP "Reply-To" syntax; if
   the :from value is specified and has valid syntax, the notification
   MUST include the "Reply-To" SIP header field containing the value of
   the :from notify tag.  If the value has invalid syntax, this is
   considered a Sieve script processing error. [[anchor6: Should the
   value be ignored instead?]]

2.3.  Notify tag ":options"

   Handling of the ":options" tag is implementation specific.  This
   document doesn't require presence of any option and doesn't define
   how options are processed.



Melnikov, et al.         Expires August 20, 2008                [Page 3]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


2.4.  Notify tag ":importance"

   The value of the ":importance" tag MAY be transformed into SIP
   "Priority" header field (in addition to or instead of including in
   the default message); if specified, the value of the "Priority"
   header field MUST be "urgent" if the value of the ":importance" tag
   is "1", "normal" if the value of the ":importance" tag is "2", or
   "non-urgent" if the value of the ":importance" tag is "3".

2.5.  Notify tag ":message"

   If included, the ":message" tag MUST be transformed into the message-
   body of a SIP MESSAGE, which MUST have Content-Type value of "text/
   plain" with CHARSET="UTF-8". [[anchor10: Should application/
   sieve-notification+xml Content type from draft-mahy-sieve-notify-sip
   be used instead?]]  If not included, the default message body SHOULD
   contain values of the "From" and "Subject" header fields of the
   triggering email message (and MAY include the value of the
   ":importance" tag, if one is specified), as shown in one of the
   examples below.

2.6.  Other Definitions

   The value of the SIP "From" header field specified in the SIP
   notification message MUST be the SIP address of the notification
   service itself.

   An implementation MUST ignore any URI parameter it does not
   understand (i.e., the URI MUST be processed as if the parameter were
   not present).  It is RECOMMENDED not to use the hname "body"
   parameter value as the message-body of the SIP MESSAGE request.  If
   hname "body" parameter and ":message" tag are present at the same
   time, the "body" parameter MUST be ignored.[[anchor11: Any other SIP
   URI parameters that should be used?]]

   The policy of retry delivery of a notification is a matter of
   implementation and is not specified herein.  But it SHOULD follow the
   suggestion for retry in RFC 3261 [SIP].

2.7.  Test notify_method_capability

   The notify_method_capability test for "online" may return "yes" or
   "no" only if the Sieve processor can determine with certainty whether
   or not the recipient of the notification message is can receive the
   notification immediately.  Otherwise, the test returns "maybe" for
   this notification method. [[anchor12: Add some specific details
   regarding determining online status of the recipient.  Also need to
   add some text about presence leak?]]



Melnikov, et al.         Expires August 20, 2008                [Page 4]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


3.  Examples

   In the following examples, the sender of the email has an address of
   juliet@example.org, the entity to be notified has a SIP address of
   <sip:romeo@example.com>, and the notification service has a SIP
   address <sip:notifier@example.com>.

   The following is a basic Sieve notify action with only a method:

   notify "sip:romeo@example.com"

   The resulting SIP MESSAGE request might be as follows:

      MESSAGE sip:romeo@example.com SIP/2.0
      Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse
      Max-Forwards: 70
      From: sip:notifier@example.com;tag=32328
      To: sip:romeo@example.com
      Call-ID: asd88asd77a@1.2.3.4
      CSeq: 1 MESSAGE
      Content-Type: text/plain
      Content-Length: 53

      <juliet@example.com> wrote: Contact me immediately!

   In the example above the email message was received from
   juliet@example.com and had "Subject: Contact me immediately!"

   The following is a more advanced Sieve notify action with a method,
   importance, subject, and message:





















Melnikov, et al.         Expires August 20, 2008                [Page 5]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


   notify :importance "1"
          :message "You got new mail!"
          "sip:romeo@example.com?subject=SIEVE"

      MESSAGE sip:romeo@example.com SIP/2.0
      Via: SIP/2.0/TCP notifier.example.com;branch=z9hG4bK776sgdkse
      Max-Forwards: 70
      From: sip:notifier@example.com;tag=32328
      To: sip:romeo@example.com
      Subject: SIEVE
      Priority: urgent
      Call-ID: asd88asd77a@1.2.3.4
      CSeq: 1 MESSAGE
      Content-Type: text/plain
      Content-Length: 19

      You got new mail!


4.  Requirements Conformance

   Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve
   notification methods.  The conformance of the SIP MESSAGE
   notification mechanism is provided here.[[anchor15: This section
   needs more work.]]
   1.   An implementation of the SIP MESSAGE notification method SHOULD
        NOT modify the final notification text (e.g., to limit the
        length); however, a given deployment MAY do so.  Modification of
        characters themselves should not be necessary, since SIP MESSAGE
        body is encoded in UTF-8 [RFC3629].
   2.   An implementation MAY ignore parameters specified in the
        ":importance", and ":options" tags.
   3.   If not included, the default message body SHOULD contain values
        of the "From" and "Subject" header fields of the triggering
        email message (and MAY include the value of the ":importance"
        tag, if one is specified), as shown in one of the examples
        below.
   4.   A notification sent via the SIP message notification method MAY
        include a timestamp in the textual message. [[anchor16: Should
        the SIP Date header field be used for timestamp instead?]]
   5.   The value of the SIP "From" header field MUST be the SIP address
        of the notification service associated with the SIEVE engine.
   6.   The value of the Sieve ":from" tag MUST be transformed into the
        value of an SIP "Reply-To" header field.
   7.   The value of the SIP "To" header field MUST be the SIP address
        specified in the SIP URI contained in the "method" parameter.





Melnikov, et al.         Expires August 20, 2008                [Page 6]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


   8.   An implementation MUST ignore any URI parameters it does not
        understand (i.e., the URI MUST be processed as if the action or
        parameter were not present).  See Section 2.6 for more details.
   9.   An implementation MUST NOT include any other extraneous
        information not specified in parameters to the notify action.
   10.  The notify_method_capability test for the "online" notification-
        capability behaves as described in Section 2.7.


5.  Security Considerations

   [[anchor17: TBD]]

   Depending on the information included, sending a notification can be
   comparable to forwarding mail to the notification recipient.  Care
   must be taken when forwarding mail automatically, to ensure that
   confidential information is not sent into an insecure environment or
   over an insecure channel.

   UAs that support the MESSAGE request MUST implement end-to-end
   authentication, body integrity, and body confidentiality mechanisms.

   Other security considerations given in [NOTIFY], [SIEVE] and [SIP]
   are also relevant to this document.


6.  IANA Considerations

   The following template provides the IANA registration of the Sieve
   notification mechanism specified in this document:

   To: iana@iana.org
   Subject: Registration of new Sieve notification mechanism
   Mechanism name: sip-message
   Mechanism URI: RFC 3261 [SIP]
   Mechanism-specific options: none
   Standards Track/IESG-approved experimental RFC number: [RFC XXXX]
   Person and email address to contact for further information:
       See authors of [RFC XXXX]

   This information should be added to the list of Sieve notification
   mechanisms maintained at
   <http://www.iana.org/assignments/sieve-notification>.


7.  Acknowledgements

   This document borrows some text from draft-ietf-sieve-notify-xmpp.



Melnikov, et al.         Expires August 20, 2008                [Page 7]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


8.  Normative References

   [NOTIFY]   Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
              Martin, "Sieve Extension: Notifications",
              draft-ietf-sieve-notify-12 (work in progress),
              December 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [SIEVE]    Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", RFC 5228, January 2008.

   [SIP]      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.


Authors' Addresses

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: Alexey.Melnikov@isode.com
   URI:   http://www.melnikov.ca/


   Henning Schulzrinne
   Columbia U.
   Columbia University Department of Computer Science
   New York, NY  10027
   US

   Phone: +1 212 939 7004
   Email: hgs@cs.columbia.edu




Melnikov, et al.         Expires August 20, 2008                [Page 8]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


   Qian Sun
   Huawei Technologies
   Bantian Longgang
   Shenzhen, Guandong  518129
   P.R China

   Phone: +86 755 28780808
   Email: sunqian@huawei.com











































Melnikov, et al.         Expires August 20, 2008                [Page 9]


Internet-Draft       Sieve Notification: SIP MESSAGE       February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 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 provided by the IETF
   Administrative Support Activity (IASA).





Melnikov, et al.         Expires August 20, 2008               [Page 10]