Subject: Re: [Sipping] draft-rajesh-sipping-303-01.txt

From: [email-masked]
Date: Fri, 13 Apr 2007 18:00:38 -0400

In regard to draft-rajesh-sipping-303-01, which defines a new 303
response code that requires an upstream proxy to recurse (rather than
simply *permitting* it to recurse):

First, the motivations need to be explained much more thoroughly.
They really are the *essence* of the proposal, so they shouldn't just
be the second and third paragraphs of the Introduction.  (And in the
third paragraph, the motivation is "it is a requirement..." without
any explanation of *why* it is a requirement.  And history provides
many examples of people who thought they had one requirement but
actually had another.)

Second, there seem to be considerable upward-compatibility problems.
Currently, proxies can generally be divided into two classes -- those
than can recurse on 3xx and do, and those that cannot recurse on 3xx
and do not.  The I-D envisions a third class, proxies that can recurse
but due to some policy will not always recurse, but which a UAS can
force to always recurse with 303.  Until proxies of the third class
exist, 303 will cause no new behavior (of the type you are interested
in).

Worse, consider the situation where the UAS wants to redirect the
request to another UAS but in a way that will not reveal the
destination UAS's URI to the UAC (section 1, paragraph 2, sentence 2).
If the upstream proxies do not support 303 and do not recurse, they
will pass the 303 response back to the UAC, violating the privacy
objective -- The mechanism does not fail-safe.  (And it's not clear
that the objective can be achieved at all without a privacy service,
as the UAS will provide a Contact URI that will likely resemble the
Contact in the 303 that we wish to keep private.)

Third, there is too much concern about which proxy is responsible for
the callee domain (and thus is obligated to recurse on the 303).  That
criterion actually isn't definable, given that the call can be
redirected from one AOR to another several times, and each AOR may
have a different domain -- until the call is accepted by a user agent,
the *actual* callee is unknowable by all SIP agents.  The real point
of concern is that the UAS generating the 303 and the upstream proxy
which recurses on it should be within the same administrative domain.
And that concern cuts both ways:

1) It makes this mechanism harder to define, because the real goal is
   to ensure that the 303 does not escape from the administrative
   domain containing the UAS that generated it, and ensuring a
   negative is difficult.

2) Whatever mechanism ensures that the proxy implements the 303
   semantics can be used as easily to ensure that it recurses on all
   3xx responses.

And some editorial suggestions:

Don't say "internally routable", say "not globally routable".  We
assume that it's internally routable, what is interesting is that it's
not globally routable.

There is a reference "(1)" which seems to have little to do with the
bibliography.

The example call flow needs to be reduced to 80 columns.

The terminology should be more consistent.  E.g., one sentence uses
both "UAS" and "server".

A considerable amount of section 2 repeats behavior defined in 3261.
I think that the only addition to 3261 behavior is the assumption that
the UAS desires to enforce recursion at a "near" upstream proxy for
one of the reasons mentioned previously.  That can be said quite
briefly.

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP