[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: January 4, 2011                                     Columbia U.
                                                                  Q. Sun
                                                     Huawei Technologies
                                                            July 3, 2010


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

Abstract

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 4, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Melnikov, et al.         Expires January 4, 2011                [Page 1]

Internet-Draft       Sieve Notification: SIP MESSAGE           July 2010


   described in the Simplified BSD License.

   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.


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 January 4, 2011                [Page 2]

Internet-Draft       Sieve Notification: SIP MESSAGE           July 2010


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 January 4, 2011                [Page 3]

Internet-Draft       Sieve Notification: SIP MESSAGE           July 2010


   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 January 4, 2011                [Page 4]

Internet-Draft       Sieve Notification: SIP MESSAGE           July 2010


   suggestion for retry in RFC 3261 [SIP].[[anchor12: Is this correct?
   When one would possibly want to violate suggestions from RFC 3261?
   If this is not correct, then the paragraph should read instead: The
   policy of retry delivery of a notification is specified in
   [RFC3261].]]

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. [[anchor13: 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 January 4, 2011                [Page 5]

Internet-Draft       Sieve Notification: SIP MESSAGE           July 2010


   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.[[anchor16: 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 January 4, 2011                [Page 6]

Internet-Draft       Sieve Notification: SIP MESSAGE           July 2010


   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

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


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 January 4, 2011                [Page 7]

Internet-Draft       Sieve Notification: SIP MESSAGE           July 2010


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 January 4, 2011                [Page 8]

Internet-Draft       Sieve Notification: SIP MESSAGE           July 2010


   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 January 4, 2011                [Page 9]


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