|-------| | |
| MMS | | |
| USER |---------------------------| |
| DBs |<- MM6 ->| |
|-------| | |
| |
|-------| | |
| MMS | | |
| VAS |---------------------------| |
| APPs |<- MM7 ->| |
|-------| |------------|
MMS - Multimedia Messaging Service
UMS - Unified Messaging Service
HLR - Home Location Register
DB - Data Base
VAS - Value Added Service
APP - Application
9. Security Considerations
Security will be a very important part of enhanced messaging. The
goal, wherever possible, is to preserve the semantics of existing
messaging systems and to meet the (existing) expectations of users
with respect to security and reliability.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[2] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[3] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC 3461,
January 2003.
[4] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[7] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text ", RFC
2047, November 1996.
[8] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996.
[10] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[11] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997.
[12] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[13] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail
- version 2 (VPIMv2)", RFC 3801, June 2004.
[14] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s
Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-
type Registration", RFC 3802, June 2004.
[15] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header
Definition", RFC 3803, June 2004.
[16] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
Rafferty, "File Format for Internet Fax", RFC 3949, February
2005.
[17] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -
image/tiff MIME Sub-type Registration", RFC 3302, September
2002.
[18] Allocchio, C., "Minimal GSTN address format in Internet Mail",
RFC 3191, October 2001.
[19] Allocchio, C., "Minimal FAX address format in Internet Mail",
RFC 3192, October 2001.
[20] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of
Facsimile Using Internet Mail", RFC 3965, December 2004.
[21] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - F
Profile for Facsimile", RFC 2306, March 1998.
[22] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
[23] Masinter, L. and D. Wing, " Extended Facsimile Using Internet
Mail", RFC 2532, March 1999.
[24] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[25] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[26] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[27] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
[28] Burger, E., "Critical Content Multi-purpose Internet Mail
Extensions (MIME) Parameter", RFC 3459, January 2003.
[29] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180,
July 1997.
[30] Candell, E., "High-Level Requirements for Internet Voice Mail",
RFC 3773, June 2004.
[31] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
April 2003.
[32] Nerenberg, "IMAP4 Channel Transport Mechanism", Work in
Progress, November 2001.
[33] Toyoda, K. and D. Crocker, "SMTP Service Extensions for Fax
Content Negotiation", Work in Progress, February 2003.
[34] McRae, S. and G. Parsons, "Internet Voice Messaging (IVM)", RFC
4239, November 2005.
[35] Murchison, K. and L. Greenfield, "LMTP Service Extension for
Ignoring Recipient Quotas", Work in Progress, June 2002.
[36] Crispin, M., "Message Submission", Work in Progress,
February 2004.
[37] Newman, C., "Message Submission with Composition", Work in
Progress, February 2004.
[38] Gellens, R., "IMAP Message Submission", Work in Progress,
December 2003.
[39] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE
Extension", Work in Progress, December 2003.
[40] Crispin, M. and C. Newman, "Internet Message Access (IMAP) -
URLAUTH Extension", Work in Progress, July 2004.
[41] Newman, D., "Message Submission BURL Extension", Work in
Progress, July 2004.
[42] Crocker, D., "Internet Mail Architecture", Work in Progress,
July 2004.
[43] Leuca, I., "Multimedia Messaging Service", Presentation to the
VPIM WG, IETF53 Proceedings , April 2002.
[44] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", RFC
3842, August 2004.
[45] Shapira, N. and E. Aloni, "Simple Notification and Alarm
Protocol (SNAP)", Work in Progress, December 2001.
[46] Vaudreuil, G., "Messaging profile for telephone-based Messaging
clients", Work in Progress, February 2002.
[47] Burger, E., "Internet Unified Messaging Requirements", Work in
Progress, February 2002.
[48] OMA, "Multimedia Messaging Service Architecture Overview
Version 1.1", Open Mobile Alliance (OMA) OMA-WAP-MMS-ARCH-v1_1-
20021101-C, November 2002.
[49] OMA, "Push Architectural Overview", Open Mobile Alliance
(OMA) WAP-250-PushArchOverview-20010703-a, July 2001.
[50] OMA, "Push Access Protocol Specification", Open Mobile Alliance
(OMA) WAP-247-PAP-20010429-a, April 2001.
[51] OMA, "Push Proxy Gateway Service Specification", Open Mobile
Alliance (OMA) WAP-249-PPGService-20010713a, July 2001.
[52] OMA, "Multimedia Messaging Service; Client Transactions Version
1.1", Open Mobile Alliance
(OMA) OMA-WAP-MMS-CTR-v1_1-20021031-C, October 2002.
[53] OMA, "Multimedia Messaging Service; Encapsulation Protocol
Version 1.1", Open Mobile Alliance (OMA) OMA-MMS-ENC-v1_1-
20021030-C, October 2002.
[54] OMA, "User Agent Profile, Version 1.1", Open Mobile Alliance
(OMA) OMA-UAProf-v1_1-20021212-C, December 2002.
[55] OMA, "Email Notification Version 1.0", Open Mobile Alliance
(OMA) OMA-EMN-v1_0-20021031-C, October 2002.
[56] 3GPP, "Third Generation Partnership Project; Technical
Specification Group Services and System Aspects; Service
aspects; Functional description; Stage 1 Multimedia Messaging
Service", 3GPP TS 22.140, 2001.
[57] 3GPP, "Third Generation Partnership Project; Technical
Specification Group Terminals; Multimedia Messaging Service
(MMS); Functional description; Stage 2", 3GPP TS 23.140, 2001.
[58] 3GPP2, "Short Message Service (SMS)", 3GPP2 TSG C.S0015-0,
December 1999.
[59] 3GPP2, "Enhanced Message Service (EMS) Stage 1 Description",
3GPP2 TSG S.R0051-0 v1.0, July 2001.
[60] CCITT, "Recommendations Q.700-Q.716: Specifications of
Signalling System No. 7", CCITT White Book, Volume VI,
Fascicle VI.7.
[61] CCITT, "Recommendations Q.721-Q.766: Specifications of
Signalling System No.7", CCITT White Book, Volume VI,
Fascicle VI.8.
[62] ITU, "E.164: The international public telecommunication
numbering plan", ITU-T Recommendations Series E, May 1997.
[63] ITU, "Specifications of Signalling System Number 7", ITU White
Book, ITU-T Recommendation Q.763.
[64] ITU, "Interface between Data Terminal Equipment (DTE) and Data
Circuit-terminating Equipment (DCE) for terminals operating in
the packet mode and connected to public data networks by
dedicated circuit", ITU-T Recommendation X.25, October 1996.
[65] BELLCORE, "Specifications of Signalling System Number 7", GR-
246-CORE Issue 1, December 1994.
Appendix A. Contributors
Eric Burger
Brooktrout Technology, Inc.
18 Keewaydin Dr.
Salem, MA 03079
USA
Phone: +1 603 890-7587
EMail: eburger@brooktrout.com
Yair Grosu
Comverse
29 Habarzel St.
Tel-Aviv 69710
Israel
EMail: Yair.Grosu@comverse.com
Glenn Parsons
Nortel Networks
P.O. Box 3511 Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763-7582
EMail: gparsons@nortelnetworks.com
Milt Roselinsky
Openwave Systems, Inc.
530 E. Montecito St.
Santa Barbara, CA 93103
USA
Phone: +1 805 884-6207
EMail: milt.roselinsky@openwave.com
Dan Shoshani
Comverse
29 Habarzel St.
Tel-Aviv 69710
Israel
EMail: Dan.Shoshani@comverse.com
Alan K. Stebbens
Openwave Systems, Inc.
530 E. Montecito St.
Santa Barbara, CA 93103
USA
Phone: +1 805 884-3162
EMail: alan.stebbens@openwave.com
Gregory M. Vaudreuil
Lucent Technologies
7291 Williamson Rd.
Dallas, TX 75214
USA
Phone: +1 214 823-9325
EMail: GregV@ieee.org
Appendix B. Acknowledgements
Ari Erev and Noam Shapira (both from Comverse) contributed
substantial requirements for IMAP to support a telephone-based (TUI)
messaging client. Meir Mendelovich (Comverse) helped in merging the
wireless requirements section. Benjamin Ellsworth (Openwave)
contributed to mobile messaging architectures and requirements.
Yaacov (Jerry) Weingarten (Comverse) and Stephane Maes (Oracle)
provided detailed comments on the final document.
Appendix C. IAB Note: Unified Notification Protocol Considerations
Note: dated July 10, 2003
This note was formulated in response to an informal IESG request to
look at the architectural issues surrounding a unified notification
protocol. The following materials were used as reference:
* draft-dusseault-s2s-event-reqs-00.txt (notification
requirements)
* meeting notes for the LEMONADE WG from IETF 56.
* draft-shapira-snap-05.txt (protocol design for SNAP which has
some aspects of a generic notification protocol)
* the LEMONADE WG charter
* Recent email on the Lemonade list
* A few presentations from the 1998 UCI workshop on Internet-wide
notification
* The Web pages for KnowHow, a company founded by Rohit Khare
which has a proprietary Internet-wide notification system.
Thanks to Lisa Dusseault for providing these references.
Note that this opinion does not represent IAB concensus, it is just
the opinion of the author after having reviewed the references.
After the reviewing the material, it seemed that the same kinds of
functionality are being asked from a generic notification protocol as
are asked of desktop application integration mechanisms, like OLAY/
COM on Windows or like Tooltalk was on Solaris, but at the level of
messaging across the Internet. The desire is that various
distributed applications with different application specific
mechanisms should be able to interoperate without having an n x n
problem of having each application interact with each other
application. The cannonical example, which is in a presentation by
Lisa Dusseault to LEMONADE from IETF 56, is sending a notification
from one application, like XMPP Instant Messaging, and having it
delivered on whatever device the recipient happened to be using at
the time, like SMS on a cell phone.
The usual problem with application intergration mechanisms on the
desktop is how to get the various applications to actually use the
mechanism. For Windows, this is relatively easy, since most
application developers see major value-added in their applications
being able to play nicely with Microsoft Office. For Tooltalk,
unfortunatly, Solaris developers didn’t see the 10x improvement, and
so it was not used outside of Sun’s internally maintained
applications and a few flagship applications like Framemaker. If the
generic notification mechanism requires application developers and
other notification protocol designers to make a major effort to
utilize it, including modifying their applications or protocols in
some way, the protocol could become "just another notification
mechanism" rather than a unifying device, because most application
developers and other protocol designers could ignore it.
So the first architectural consideration is how do clients of a
particular protocol (and the word "client" is used here to mean "any
entity using the protocol", they may peers or they may be
client/server) actually utilize the generic notification protocol?
Is there some code change required in the client or can a legacy
client interoperate without change?
If you look at Fig. 1 in draft-shapira-snap-05.txt, the answer seems
to be that the notifying client uses the generic protocol, SNAP in
this case, to a functional entity (server? module on the receiving
client?) called the "Notification Service" that processes the generic
notification into an application specific notification and sends that
notification to the client. From this figure it looks as if the
notifying client would require modification but the receiving client
wouldn’t.
Another characteristic of application integration mechansims is that
they typically focus on very simple operations, the semantics of
which are shared between different applications. Examples are
"here’s a rectangle, display yourself in it" or "put this styled text
object into the clipboard", and applications agree on what styled
text means. More complicated semantics are hard to share because
each application has its own particular twist on the meaning of a
particular sequence of operations on a collection of objects. The
result is a "least common denominator" collection of integration
mechanisms, primarily focussed on display integration and, to a
lesser extent, cut and paste integration.
In the context of a generic notification protocol, this raises
several possible issues. One is addressing, which is identified
draft-dusseault-s2s-event-reqs-00.txt, but in a sense this is the
easiest to resolve, by using existing and perhaps newly defined URIs.
A more complex problem is matching the semantics of what
preconditions constitute the trigger for an event across different
application notification mechanisms. This is of course necessary for
translating notifications between the different event notification
mechanisms and the generic mechanism, but, more problematically, it
is also required for a subscription service whereby subscriptions can
be made to filter events using the generic notification mechanism and
the subscriptions can be translated to different application specific
mechanisms. Any language for expressing generic subscriptions is
unlikely to support expressing the fine points in the different
application notification semantics. Note that SNAP does not seem to
support a subscription service so perhaps this isn’t an issue for
SNAP.
Another architectural issue, which was discussed earlier this year on
the LEMONADE list w.r.t. some other topics, is gatewaying. The
cannonical example above (message sent using XMPP and arriving via
SMS on a cell phone) is actually a gateway example, because it would
require translation between an IP-based messaging mechanism (XMPP) to
a PSTN based mechanism (SMS). The problem with using a unified
notification mechanism for this purpose is that if there are other
functions common between the two, it is likely that a gateway will be
built anyway. In fact, one of the work items for LEMONADE is to
investigate such gateways. The value of a generic notification
mechanism therefore needs to be assessed in the light of this.
These are the primary architectural issues, but there are a few
others that need consideration in any major system development
effort. End to end security is one,
draft-dusseault-s2s-event-reqs-00.txt talks about this quite
extensively, so it won’t be repeated here. The major issue is how to
ensure that the end to end security properties are maintained in the
face of movement of the notification through the generic intermediary
protocol. Another issue is scalability. Peer to peer v.s. server
based mechanisms have implications for how scalable the notification
mechanism would be, and this needs consideration. Extensibility
needs careful consideration. What is required to integrate a new
application? Ideally, with time, application developers will stop
"rolling their own" notification service and simply use the generic
service, but this ideal may be extremely hard to achieve, and may
depend to a large extent on market acceptance.
Finally, there are some considerations that aren’t architectural but
may impact the ultimate success of a generic notification protocol,
in the sense that the protocol becomes widely deployed and used. The
author’s experience is that IETF has not had particular success in
introducing mechanisms that unify or supplant existing proprietary
mechanisms unless strong vendor and service provider by-in is there.
Two examples are instant messaging and service discovery. With
instant messaging, it seems that a standarized, unified instant
messaging protocol has been delayed by the lack of committment from
major service providers. With service discovery, weak commitment
from vendors has resulted in the continued introduction of vendor
specific service discovery solutions even after an IETF standard is
in place. The situation with service discovery (with which the
author is most familiar) resulted from a lack of major vendor
committment during the end phases of the standarization process.
Applying these lessions to a generic notification protocol, having
important players with proprietary notification protocols on board
and committed until the conclusion of the design process will be
crucial. Major committment is needed from various application
notification protocols before a generic mechanism could succeed.
Given the amount of time and effort required in any IETF
standardization work, assessing these with an objective eye is
critical, otherwise, regardless of how technically well designed the
protocol is, deployment success may be lacking. Having an elegently
design solution that nobody deploys is an outcome that might be wise
to avoid.
James Kempf
July 2003
Author’s Address
Jin Kue Wong (Editor)
Nortel Networks
P.O. Box 3511 Station C
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763-2515
EMail: j.k.wong@sympatico.ca
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).