RE: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt

["Francois Audet" <audet at nortel.com>]

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.

My 2 cents....


 

> -----Original Message-----
> From: Barnes, Mary (RICH2:B601) 
> Sent: Monday, September 11, 2006 9:20 AM
> To: sipping at ietf.org
> Subject: [Sipping] WGLC: draft-ietf-sipping-dialogusage-03.txt
> 
> Hi all,
> 
> This is to announce Working Group Last Call on the following 
> draft 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogu
> sage-03.tx
> t
> 
> We alredy have 3 volunteer reviewers assigned (Paul Kyzivat, 
> Derek MacDonald and Vijay Gurbani), but additional volunteers are also
> welcome:
> http://www.softarmor.com/sipping/process/wg-review/sipping-rt.html
> 
> The spreadsheet will be updated shortly to reflect the state 
> of this document in WGLC. 
> 
> As always, anyone else that gets a chance to review should 
> also send their feedback to the authors and copy the SIPPING 
> mailing list. 
> 
> This WGLC will end on Oct 2nd, 2006 (three weeks time). 
> 
> Thanks,
> Mary
> SIPPING WG co-chair
> 
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use sip-implementors at cs.columbia.edu for questions on current 
> sip Use sip at ietf.org for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP