\section{Changes Needed for Draft Version}
\begin{itemize}

\item \header{In-Reply-To}.

\item Ping liveness detection. Motivation:
\motivation{A proxy may be keeping track of a call during its entire
duration, for example to maintain consistent routing for all subsequent
requests.  The proxy enforces that requests traverse it by using
\header{Record-Route}.  If, however, a {\BYE} fails to arrive at the
termination of a call (e.g., because of application failure or network
partition), the proxy must know to delete the call record.  If the proxy
deletes a call record before a session is terminated (by timeout, for
example), it makes the routing of subsequent call messages impossible
(since the information regarding the ultimate destination of an
{\INVITE} may no longer be available).  Without the ability for a proxy
server to check the liveness of a session, there is no way to rectify
this problem.}

Solutions suggested:

\item proxy sends re-INVITE;
\item session lifetime;
\item A PING request would be retransmitted (T1, doubled each time, max of
T2, up to 11 times) until a provisional or final response is received. 
Once that is accomplished, it is only retransmitted at the frequency
specified in the "Period" header.  As long as another provisional
response is received in at the freqency specified in the "Period"
header, the PING is not retransmitted.

\item The {\OPTIONS} request is answered with a special 2xx status if
the call leg exists at the server. (What about changes in SDP?)

\item (?) Add redirection history. May have privacy implications.

\item Add session lifetime as SIP header (Session-Expires?) 

\item UA Record-Route behavior:  1.  The Record-Route list from a
response must be inverted and placed in the Route header in subsequent
requests 2.  Subsequent requests are sent to the first server on the
Route list

I think even minimal implementations SHOULD do (1), so that a proxy is
burdened with remembering the Record-Routes from responses and storing
them in requests. However, (2) can be done by either the UAC or the
proxy that the UAC always sends a request to. Basically, when a proxy
receives a request with a Route header, it removes the next Route header
and forwards it there. Consider a UAC which does (1) but not (2). Now,
lets say a proxy doesn't list itself in a Record-Route header, but the
UAC always sends all requests to that proxy. When a request arrives, the
proxy follows normal Route processing rules and the message is forwarded
correctly. If the proxy does list itself in the Record-Route, the UAC
will end up sending a request to the proxy, but the top Route header in
the request is the address of the proxy itself. Thus, the proxy
shouldn't send it to this address (which would cause a loop), but rather
it should check if the top Route header is its own address, and if so
just remove it, and then send to the next address.

With this additional processing step, it is possible for UAC's to send
requests always to a specific proxy, but they still SHOULD reflect the
Record-Route headers into a Route header. I suspect this is the far
easier part of the processing in any case.


\item Expires header clarified: limits only duration of INVITE
transaction, not the actual session. SDP does the latter.

\item automatic proxy configuration; header or configuration language?

\item empty \header{To} and \header{From} in initial {\REGISTER}
requests (agreed);

\item \header{received-port} for NAPT support in \header{Via} header field;

\item Proxy authentication:  If a forking proxy adds or changes an
\header{Authorization} header, it {\MUST} change the \header{branch}
parameter in the \header{Via} header to avoid being confused by
retransmission of earlier 407 responses.  If a request triggered a 407
response, the downstream proxy inspects retransmissions of the the same
request to see if it contains new authorization header.  If so, it
re-evaluates its authentication decision.  This is a slight deviation
from the usual idempotency rules.

\item \header{In-Reply-To} and \header{References} for follow-up calls,
similar to \cite{draft-ietf-drums-msg-fmt}.

\item Use of cookies with SIP?

\end{itemize}

\section{Open Issues}

URI Syntax

The problem is that since [userinfo @] is optional, when you start
parsing after the ``scheme:'', you don't know whether this is userinfo
or hostport.  Thus, if you hit a semicolon, you won't know whether now
you are seeing parameters for the URI, or whether this is part of the
hostport.  Yes, you could first scane the whole thing for an @ sign,
then decide whether there is a userinfo, but this requires a two pass
parse.  I'd rather be able to decide once I hit a semicolon or at sign.

userinfo is defined as *( some stuff). This means there can be zero of
them,so that:

sip:@dnrc.bell-labs.com

and

sip:dnrc.bell-labs.com

I still think hname and hvalue cannot be *uric.  The "&" and "=" should
be disallowed.  I know the text says they must be escaped encoded, but
the BNF still allows them to be present, since uric includes reserved,
which includes both & and =.

Merges for forked request:

We could also solve the CANCEL problem by requiring the one Via field in
the CANCEL to contain this same identifier.

----
Move table-of-contents between abstract and intro

We *usually* abide by the "3 line rule" which is that if a 
paragraph doesn't have at least 6 lines (3 on one page, 3 on
another) then it CAN"T be broken up.  The .ne command is 
for keeping sentences together.  If it is code we just let
it run, but we try to keep paragraphs under six lines together
on the same page
