Subject: [Sipping] Comments on draft-koshiko-sipping-reason-indicating-locations-01. txt

From: "Mary Barnes" <[email-masked]>
Date: Wed, 16 Feb 2005 14:06:47 -0500

Hi Koshiko-san,

I have reviewed your revised draft and from what I can see the only change
has been the addition of a new section 3.3 with load balancing examples.  Is
that correct?   

I'm thinking perhaps my previous comments on the -00 draft were missed as
they were posted in the context of the recent discussion on extending the
Reason header
(http://www1.ietf.org/mail-archive/web/sipping/current/msg07658.html ), so
I'll go ahead and summarize the primary points:

1. The use of "location" in this draft is a bit of a misnomer, as it's not
geographic location, but rather the entity that originates a specific
message that's considered "location", so it's really more "source" than
"location".  

2. After reviewing the draft, I don't think the extension to Reason header
is the best way to achieve the desired functionality.  I think that the use
of History-Info (including the capturing of the Reason header) would provide
the necessary information that the client can use to derive the "source" of
a specific Response code or Request (e.g. CANCEL).   The draft clearly
states that the desired information is the "how and why a SIP messages
arrives at a specific application" and that's clearly the intent of
History-Info. Record-Route might also be useful in some of the scenarios.  
 
I think a useful exercise in a revision to your draft would be to go through
your examples using History-Info, including the Reason header, where
appropriate to indeed determine whether this isn't sufficient.  Until, we
can see that there are gaps and/or deficiencies in that approach, I don't
think it's prudent to be considering yet another set of extensions to the
Reason header. 

Regards,
Mary H. Barnes

_______________________________________________
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