Subject: [Sipping] More Holiday Reading: Updates to Request History Solution draft

From: "Mary Barnes" <[email-masked]>
Date: Thu, 19 Dec 2002 21:04:14 -0600

Hi all,

I have submitted an updated version of the request history solution draft.
Until it's available in the repository, it's available at:
http://home.attbi.com/~mbarnes42/IETF/draft-barnes-sipping-history-info-01.t
xt

For folks that might have read the previous document or followed the
discussion in Atlanta, the changes made are as follows:

1. Updated the ABNF and discussion of usage in Section 2 per the discussion
in Atlanta:
- capturing a single Request URI (by capturing the original URI prior to
retargeting and then letting the previous entry reflect the "from" for the
current instance of retargeting).
- with only a single URI captured, an explicit index is required.
- removed the explicit Reason fields as we can reuse the Reason Header (RFC
3326)

2. Consistent with the changes to the requirements document, described that
the security solution will be documented in a separate draft. This draft
will need to be updated once that work is more complete; I've started a
draft of that work, but it's not likely to be available until sometime in
Jan. timeframe. 

3. Other minor updates to section 1 to ensure the solution description is
consistent with section 2. 

Items requiring further discussion:

Issue1: Forking still requires further detail, although the addition of an
explicit index does make forking easier to track in the messages. However,
as mentioned in the presentation in Atlanta, further scenarios need to be
detailed to ensure that there isn't additional functionality required to
capture HI for these scenarios. 

Issue2:  The current solution for the index option is to use a dot delimited
counter (option a presented in Atlanta), such that forking and nesting of
requests are obvious from the index (previously, with both URIs captured,
the forking and nesting would have to be derived from the URIs).  At this
time, the index is an optional parm, but without it, you can't rebuild the
logical forking and nesting.  I think this is important for some potential
applications of HI (i.e. diagnostics), but not so important for others.  So,
are folks okay with the optionality of this parm or should it be mandatory?
It should also be noted that the other options considered for the
index/counter are described in appendix D. 

Issue3: The primary offline and some recent online discussion of HI has been
around the privacy aspects.  At this time, there hasn't been changes to
either the requirements or proposed solution for support of this as much of
it is either beyond the scope of HI (i.e. is application specific) or is
sufficiently covered by the Privacy draft.  This is not so much an issue,
but a request for folks with expertise in this area to carefully review this
section of the requirements and solution drafts. 

There is of course, the general issue that I still need to complete further
message flows and add more detail to the scenarios that are there, but I did
want to get some initial feedback on the solution as it now stands and
consensus around some of the issues. 

Regards,
Mary H. Barnes
[email-masked]
972-684-5432

_______________________________________________
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