[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-melnikov-sieve-notify-sip-message) 00 01 02 03 04 05 06 07 08 RFC 6468

Network Working Group                                        A. Melnikov
Internet-Draft                                             Isode Limited
Intended status: Standards Track                          H. Schulzrinne
Expires: September 8, 2009                                   Columbia U.
                                                                  Q. Sun
                                                     Huawei Technologies
                                                           March 7, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 September 8, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the



Melnikov, et al.        Expires September 8, 2009               [Page 1]

Internet-Draft       Sieve Notification: SIP MESSAGE          March 2009


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

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


Table of Contents

   1.    Conventions Used in this Document . . . . . . . . . . . . . . 3

   2.    Introduction  . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3

   3.    Definition  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.1.  Notify parameter "method" . . . . . . . . . . . . . . . . . . 3
   3.2.  Notify tag ":from"  . . . . . . . . . . . . . . . . . . . . . 3
   3.3.  Notify tag ":options" . . . . . . . . . . . . . . . . . . . . 4
   3.4.  Notify tag ":importance"  . . . . . . . . . . . . . . . . . . 4
   3.5.  Notify tag ":message" . . . . . . . . . . . . . . . . . . . . 4
   3.6.  Other Definitions . . . . . . . . . . . . . . . . . . . . . . 4
   3.7.  Test notify_method_capability . . . . . . . . . . . . . . . . 5

   4.    Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . 5

   5.    Requirements Conformance  . . . . . . . . . . . . . . . . . . 6

   6.    Security Considerations . . . . . . . . . . . . . . . . . . . 7

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

   8.    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 8

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

         Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 8






Melnikov, et al.        Expires September 8, 2009               [Page 2]

Internet-Draft       Sieve Notification: SIP MESSAGE          March 2009


1.  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].


2.  Introduction

2.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]).

2.2.  Terminology

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


3.  Definition

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

3.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 included and MUST contain the
   value "MESSAGE".  (Note that future specifications might extend this
   document and define Sieve notifications that use other SIP methods.)
   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.

3.2.  Notify tag ":from"

   The value of the ":from" tag MUST use the SIP "From" header field
   syntax; if the :from value is specified, has valid syntax, and is



Melnikov, et al.        Expires September 8, 2009               [Page 3]

Internet-Draft       Sieve Notification: SIP MESSAGE          March 2009


   valid according to the implementation-specific security checks (see
   Section 3.3 of [NOTIFY]), then the notification SHOULD include the
   "From" SIP header field containing the value of the :from notify tag.
   If the specified value is not valid, then it is ignored.

3.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.

3.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".

3.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.

3.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



Melnikov, et al.        Expires September 8, 2009               [Page 4]

Internet-Draft       Sieve Notification: SIP MESSAGE          March 2009


   suggestion for retry in RFC 3261 [SIP].

3.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.]]


4.  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;method=MESSAGE"

   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 September 8, 2009               [Page 5]

Internet-Draft       Sieve Notification: SIP MESSAGE          March 2009


   notify :importance "1"
          :message "You got new mail!"
          "sip:romeo@example.com;method=MESSAGE?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!


5.  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: Need to compare
   this section with XMPP NOTIFY (RFC 5437) and Email NOTIFY (RFC
   5436).]]
   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
       SHOULD include the Date header field containing the date-time of
       the moment when the SIP MESSAGE notification was generated.
   5.  The value of the Sieve ":from" tag SHOULD be transformed into the
       value of an SIP "From" header field, if it has valid syntax and
       is valid according to the implementation-specific security checks
       (see Section 3.3 of [NOTIFY].  If ":from" is not specified or is
       not valid, the SIP "From:" header field of the notification
       message SHOULD be set to the SIP address of the notification
       service associated with the SIEVE engine.




Melnikov, et al.        Expires September 8, 2009               [Page 6]

Internet-Draft       Sieve Notification: SIP MESSAGE          March 2009


   6.  The value of the SIP "To" header field MUST be the SIP address
       specified in the SIP URI contained in the Sieve notify "method"
       parameter.
   7.  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 3.6 for more details.
   8.  An implementation MUST NOT include any other extraneous
       information not specified in parameters to the notify action.
   9.  The notify_method_capability test for the "online" notification-
       capability behaves as described in Section 3.7.


6.  Security Considerations

   [[anchor16: 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.


7.  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: SIP/SIPS as specified in 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>.





Melnikov, et al.        Expires September 8, 2009               [Page 7]

Internet-Draft       Sieve Notification: SIP MESSAGE          March 2009


8.  Acknowledgements

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

   The authors would like to specially thank Adam Roach and Eric Burger
   for their helpful comments.


9.  Normative References

   [NOTIFY]   Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
              Martin, "Sieve Extension: Notifications", RFC 5435,
              January 2009.

   [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/







Melnikov, et al.        Expires September 8, 2009               [Page 8]

Internet-Draft       Sieve Notification: SIP MESSAGE          March 2009


   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


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

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

































Melnikov, et al.        Expires September 8, 2009               [Page 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/