Subject: [Simple] gathering open items

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Mar 2001 16:47:03 -0500

Here are the open items copied from the -presence-01 and -im-01 drafts.

What's known open items are missing?

List discussion on any of these items this week is strongly encouraged.

--------------

Presence:
1) This draft recommends that the To and From field are populated with
presence URLs rather than sip URLs. Is that reasonable? Will this lead to
incompatibilities in proxies? Is there any issues with CPIM if the SIP URL
format is used? This depends on what components of a message are signed in
CPIM. 

2) Rate limitations on NOTIFY: do we want that? How do we pick a value? 5
seconds is arbitrary. 

3) Merging of presence data from multiple PA has been removed. Is that OK? 

4) Placing IM URLs in the Contact header of a REGISTER: is that OK? What
does it mean? 

5) The process of migrating subscriptions from a presence server to PUA is
not likely to work in the case where subscription refreshes use tags and
Route headers. So, we have a choice. Either migration is disallowed, and we
keep with leg oriented subscriptions, or migration is allowed, and there is
no tags or Route's associated with subscriptions. 

6) Converting SIP URLs back to pres URLs. 

7) The SIP to CPIM and CPIM to SIP gateways are not stateless, because of
the need to maintain Route, Call-ID, CSeq, and other parameters. Perhaps we
can ask CPIM to define a token value which is sent in a CPIM request and
returned in a CPIM response. Would that help? 

8) Need to specify how to take Contacts from REGISTER and build a presence
document. One obvious thing is that the contact addresses don't go in there
directly; you probably want to put the address of record, otherwise calls
might not go through the proxy. 

IM:

1) Must a MESSAGE actually include a message? Section 5 specifies that a
MESSAGE MAY contain a MIME body. Should this be MUST? Does it make sense to
have a MESSAGE with no body? 

2) Should support for message/cpim be mandatory in all UAs? Section 5
requires that UAs implementing MESSAGE support text/plain bodies as the
lowest common denominator. Should this be message/cpim instead? Any UA
wishing to support end-end signing or encryption of messages passing across
simple/apex/prim boundaries MUST support message/cpim. If, however, end-end
security is not desired, clients and messaging can be made a little lighter
by not including the message/cpim wrapper. An unsigned message/cpim body can
be created from messages from those clients when crossing a boundary that
requires one.

3) message/cpim and the Accept header - Do we need text to make it clear
that a UA should indicate the mime types it supports _inside_ a message/cpim
body as well as supporting message/cpim? 

4) Message Sessions - Several implementations of the -00 version of this
draft grouped messages in a common thread by placing them in a "call-leg"
(common To, From, and Call-ID). The first message sent or received in a
thread established the leg. This has provided enough information to allow
user interfaces to present separate threads in separate dialogs. There is
some concern that there is no way to formally terminate this "call-leg". The
-00 version noded that there is state at the UA associated with this notion
of session, encapsulated in the Call-ID, Route headers, and CSeq numbers. A
UA MAY terminate this session at any time, including after each MESSAGE. No
messaging is required to terminate it. Any associated state with the session
is simply discarded. The idempotency of SIP requests will ensure that if one
side (side A) discards session state, and the other (side B) does not, a
message from side B will appear as a new IM, and standard processing will
reconstitute the session on side A. o Should we define a way to use
INVITE/BYE to surround a group of MESSAGE requests that are part of a
logical session?

5) What would a body in a 200 OK to a MESSAGE mean? Section 5.5 states "A
200 class response to a MESSAGE request MAY contain a body, but this will
often not be the case, since these responses are generated automatically."
If one were to appear, what would it mean? 

6) The im: URL and RFC2543 proxies and registrars What are the implications
of an im: URL showing up in the request URI in a MESSAGE request received by
an RFC2543 proxy, or the To: header of a REGISTER request received by an
RFC2543 registrar?

7) Providing im: URL in Contact headers -  What are the ramifications of a
UA providing an im: URL in a Contact: header for a REGISTER method, or a
MESSAGE method? For the forseeable future, most SIP endpoints aren't going
to have SRV records of the form _im._sip.host or even _sip.host pointing to
them. Falling back to A records in that case seems to preclude the use of
non-UDP transports.

8) Congestion control - Per the amendments made to the SIMPLE charter by the
IESG prior to approval, congestion control needs attention. In particular
the requirements of BCP 41 must be met by this extension. Specifying the use
of transport protocols with congestion control built in, particularly with
the recommendation of reuse of connections, is an option. The question is
when can we use those that don't (UDP) and what needs to be done in addition
to what SIP already does in that case. Among other things, this interacts
with Section 8.7

9) Mapping to CPIM - This document needs to detail the mapping of this
extension onto CPIM.