Draft:  draft-ietf-sipping-dialogusage-03
Reviewer: Francois Audet 
Review Date: Friday 9/15/2006 1:31 PM CST
Review Deadline: 10/02/2006
Status: WGLC 

Note: the following is some initial feedback that raises some fundamental issues on this document.  Refer to the detailed thread on the 
SIPPING list for complete details:
http://www1.ietf.org/mail-archive/web/sipping/current/msg11981.html

These comments are included since they do raise some fundamental questions on the direction of this document. 

Summary: 
--------
This draft serious issues, described in the review, and needs to be rethought. 

Comments:
---------
I do have some high-level comments on this draft.

I don't want to spoil the party, but I don't think we are
doing the right thing with dialogusage.

The draft does an excellent job of explaining the complexities
introduced by sharing the same dialog for different usages.

However, I think it will completely baffle people as it really 
doesn't offer any way out of the mess. The conclusion pretty
much says "it's a mess, we don't know how to get out of it",
and offers some vague hope that one day GRUU combined with not
using shared dialogs will solve the problem.

I'm quite worried that instead of helping, this would actually
be even more confusing for people. I'm also not that convinced
that it is realistic to think that we will be able to migrate
to a nirvana where dialogs are not shared.

So to me, the material in the draft should really be a call to action
for us to fix the problems, not just describe that all hope is lost.

Now, for specifics.

The part that bothers me the most is section 4.1 describing different
behaviors for 7-pages worth of error codes.

It seems to me insanely complicated, and furthermore, it seems unrealistic
to me to expect that implementations will follow all those rules. 

I really think we need to come up with a generic rule for error 
response codes, as as little "exceptions" as possible. 
We really should be very careful before allowing exceptions. 
Many of the exceptions listed in there may theoretically
make sense, at some intellectual level, but it is not clear 
at all that they offer any practical value.

It is also not always clear what methods the error are applicable to. 
For example, the entry for "400 and unrecognized" seems to apply
only to NOTIFY, but 403 also talks about re-INVITE (what about 
re-INVITE and 400?).

For example, let's say that we decided that 4XX response (unless 
otherwise noted) would only apply to the transaction (re-INVITE,
NOTIFY, etc.). Before we make exceptions for all possible error codes, 
we should really make sure it has benefits. To take a specific example: 
404. Why not just apply the same rule here? i.e., that it would apply
to the transaction only instead of tearing down the whole thing as per 
the current wording.

The draft makes a very good job explaining why certain error codes 
used in an existing dialog makes no sense, but the conclusion that if 
they are received "something must have gone horribly wrong and we 
should tear down the whole thing" seems like overly harsh. 
I think it will be extremely vulnerable to non-perfect implementations. 
I'd much rather have a simple rule (i.e., "applies to the transaction")
than to try to assign too many complicated rules to individual error codes.