60 likes | 164 Views
SIMPLE Advanced IM Requirements draft-ietf-simple-messaging- requirements-00. Markus Isomäki IETF 66, July 11, 2006. Background and Purpose. The current draft is a revision of draft-rosenberg-simple-messaging-requirements-01, from February 2004
E N D
SIMPLE Advanced IM Requirementsdraft-ietf-simple-messaging- requirements-00 Markus Isomäki IETF 66, July 11, 2006
Background and Purpose • The current draft is a revision of draft-rosenberg-simple-messaging-requirements-01, from February 2004 • That draft drew requirements e.g. from draft-niemi-simple-im-wireless-reqs-02, which tried to capture 3GPP/OMA related IM requirements at the time • The revision was done based on discussion within an ad hoc design team established at IETF 65 • All requirements that SIMPLE (or other related WGs) already addresses or should work upon were kept. All others were removed. • In some areas existing specifications (RFCs or matured drafts) already cover what is needed • In some areas more work is needed if we want to meet the requirements
Scope of the Requirements • IM Disposition Notifications • draft-ietf-simple-imdn tries to address these • Is-Composing • RFC 3994 (Indication of Message Composition of Instant Messaging) already addresses these • Content Capabilities (==indication of the maximum message size) • MSRP meets the requirement, SIP MESSAGE currently not • Page-Mode Groups (==addressing SIP MESSAGE to a list of recipients) • draft-ietf-sipping-uri-services and draft-ietf-sipping-uri-list-message already address these • To, Cc, Bcc “roles” as in draft-ietf-sipping-capacity-attribute not included in these reqs • Multiparty MSRP related requirements (including “private” messaging, nicknames) currently missing • Anything else SIMPLE should be working on related to IM?
Specific Open Issues Related to IMDN • IMDN and intermediaries • IMDN in session-mode messaging • REQ-DISNOT-11: When an IM is sent to an intermediary that will relay it to a group of recipients, it MUST be possible for the sender to ask that the intermediary will generate summary reports based on reports it receives from each final recipient. [OPEN ISSUE: Is this needed?] • REQ-DISNOT-12: Any error condition reported by the notification MUST be able to contain a textual description of the error meant for human consumption [OPEN ISSUE: How about internationalization?] • REQ-DISNOT-13: If an IM is being relayed through a gateway, for example, to SMS, the delivery report SHOULD be able to indicate such a condition [OPEN ISSUE: Is this needed?] • REQ-COMP-14: It must be possible to receive delivery confirmation reports for is-composing indicators [OPEN ISSUE: This is related to the question on whether disposition notifications will be supported for session-mode messaging.]
Open Issue Related to SIP MESSAGE Max-size Indication • In page mode messaging, a 413 response can be sent if a MESSAGE request is too large. However, there is no way to indicate what the largest allowed size is. • REQ-CONTENT-2: A 413 response MUST be capable of indicating the maximum allowed message size. [OPEN ISSUE: Is this needed?]
Next Steps • Are we covering all the areas where SIMPLE should work on related to IM capabilities? • Multiparty MSRP? • Should we specifically ask input e.g. from OMA? • What are they expecting IETF to deliver to them? • Resolve the IMDN related open issues in order to get draft-ietf-simple-imdn on the correct track • Resolve the SIP MESSAGE maximum size issue