Subject: [sipcore] Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries in responses

From: Mary Barnes <[email-masked]>
Date: Thu, 17 Feb 2011 12:32:13 -0600

HI John,

Responses inline below [MB2].   I'm separating the thread into two separate
emails as I think there are two distinct issues within this thread, so it
will be easier to track.

Thanks,
Mary.

On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John <
[email-masked]> wrote:

> Mary,
>
> Thanks - see below:
>
> > -----Original Message-----
> > From: Mary Barnes [mailto:[email-masked]]
> > Sent: 16 February 2011 23:29
> > To: Elwell, John
> > Cc: SIPCORE
> > Subject: Re: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt
> >
> > Hi John,
> >
> > Thanks for the comments. Responses inline below [MB].
> >
> > Mary.
> >
> >
> > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John
> > <[email-masked]> wrote:
> >
> >
> >       Mary,
> >
> >       Thanks for this major rewrite and addressing very many
> > earlier comments. I have some initial comments and also a
> > general comment.
> >
> >       Comment 1: Request fails (4xx, say) and as a result a
> > proxy retargets. According to 7.1.2, the proxy is required to
> > include in the retargeted request all entries from received
> > responses so far, including, presumably, entries in the 4xx
> > response that leads to retargeting. However, if the request
> > does not contain Supported: histinfo, there will be no
> > entries in received responses. Therefore the final UAS will
> > not receive a complete set of entries. So we seem to have the
> > strange situation that the set of entries received by the UAS
> > is dependent on support of History-Info at the UAC. This
> > seems wrong. It seems to me that entries should always be
> > sent backwards, subject to privacy, and perhaps not on the
> > last hop if the UAC doesn't support it.
> >
> >
> >  [MB]
> >
> [JRE] Your responses seems to be lost.
>
> >
> >       Comment 2: Suppose a proxy forwards a request to two
> > targets, one with entry index 1.1 and the other with entry
> > index 1.2. A provisional or final response is received to the
> > first forwarded request containing an additional entry with
> > index 1.1.1. Then a 4xx response is received to the second
> > request, causing the proxy to retarget, this time with an
> > entry index 1.3. According to 7.1.2 step 1, that retargeted
> > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note
> > that 1.1 is missing. I see nothing to require the inclusion
> > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of
> > 1.1.1. Have I misinterpreted something?
> >
> >
> > [MB] 1.1 should also be included. Perhaps the wording needs
> > clarification, but the text is attempting to state that in
> > cases where
> [JRE] Your responses seems to have been truncated.
>
[MB2] I'm not sure if that was me or the cat.    The text is attempting to
state that all the hi-entries that were sent in previous requests, along
with all the hi-entries in responses to those requests is included when the
request is again retargeted.   But, I can see that the current wording could
be read that only the hi-entries in the original request versus the original
request + any other requests for which responses have been received, as well
as the hi-entries contained in all responses.  However, I had thought the
qualification that it states "in the original request that received the
error response", so perhaps just removing the word "original" will suffice?
[/MB2]

>
> >
> >
> >       Comment 3: In 7.2 it states:
> >       "...MUST forward captured History-Info in
> >         subsequent, provisional, and final responses to the
> > request sent by
> >         the ultimate UAS (see Section 6.2)..."
> >       When a proxy forwards a provisional response, how does
> > it know that this is from the ultimate UAS? This can only be
> > known when the first 2xx arrives. In fact the term "ultimate
> > UAS" is also problematic because how does a proxy know that a
> > response has come from a UAS, as opposed to a proxy?
> >
> >
> > [MB] It doesn't know that it's the ultimate UAS, so=o we
> > should remove that phrase.  It's attempting to highlight that
> > all the information is sent in the responses, but that's
> > really covered elsewhere. [/MB]
> [JRE] It does seem to make sense to simplify it so that you send all
> information in all provisional or final responses (except 100). Just an
> example to help confirm whether this simple rule makes sense:
> A proxy forks, sending requests with indices 1.1, 1.2 and 1.3. Then the 1.3
> branch sends a response (provisional, final) containing additional entry
> 1.3.1. In this case the response that the proxy sends upstream would contain
> 1, 1.1, 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2
> branches have not responded, they are included in the upstream response?
>

[MB2] The current approach is consistent with RFC 4244 whereby only the
hi-entries for requests for which responses have been received are included
in the upstream response.  Again, it's hard for me to totally recall the
logic, but I think it was because at that point in time, you don't know what
will happen to that request - i.e., it's more misleading than helpful.
 We'd have to consider whether it would cause an issue with backwards
compatibility if we change this now. IMHO, those entries only have value if
you could accurately tag that they were outstanding or had timed out rather
than infer that because they have no reason header means that the
retargeting entity has not yet received a response. Also, per the comment
above you would also have an hi-entry with an index of  1.1.1 and that
hi-entry would have a Reason header field "escaped" in the
hi-targeted-to-uri.  Whereas, neither the 1.2 or 1.3.1 hi-entry would have a
Reason header field in the hi-targeted-to-uri. I don't see that to cause so
much confusion as there might be if it was 1.1., 1.2 and 1.3 requests had
been issued at the same time and the only response comes from 1.2, which has
an hi-entry of 1.2.1. Thus, the last hi-entry (i.e., 1.3) in the response
isn't one for which the request has received a response. [/MB2]

>
> ---- Remainder snipped and put into Part 2: Document structure
>
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Feb 2011 22:09:01 +0100

> Sent: 17 February 2011 18:32
> To: Elwell, John
> Cc: SIPCORE
> Subject: Part1: Some comments on 
> draft-ietf-sipcore-rfc4244bis-03.txt - Including all 
> hi-entries in responses
> 
> HI John, 
> 
> Responses inline below [MB2].   I'm separating the thread 
> into two separate emails as I think there are two distinct 
> issues within this thread, so it will be easier to track.
> 
> Thanks,
> Mary. 
> 
> 
> On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John 
[JRE] I still don't see your response to this one.

> [MB2] I'm not sure if that was me or the cat.    The text is 
> attempting to state that all the hi-entries that were sent in 
> previous requests, along with all the hi-entries in responses 
> to those requests is included when the request is again 
> retargeted.   But, I can see that the current wording could 
> be read that only the hi-entries in the original request 
> versus the original request + any other requests for which 
> responses have been received, as well as the hi-entries 
> contained in all responses.  However, I had thought the 
> qualification that it states "in the original request that 
> received the error response", so perhaps just removing the 
> word "original" will suffice? [/MB2]
[JRE] I am still confused by your explanation. Let me put the question a different way:
When I fork a request to several different targets, and when one of those branches returns a response which leads me to retarget, what is included in the retargeted request?
1. Clearly all entries received from upstream.
2. Clearly a new entry for the new target.
3. Clearly the entry for the request whose response caused me to retarget, and any additional entries in that response.
4. Do I include entries for other requests on other branches that have responded finally, and any additional entries in those responses, even though they have not led to retargeting? I think your intention is "yes".
5. Do I include entries for other requests on other branches that have responded provisionally, and any additional entries in those responses, even though they have not led to retargeting? I think your intention is "yes", but I am not certain (see also my comments further down concerning Reason header field - an answer of "no" might make more sense).
6. Do I include entries for other requests on other branches that have not yet responded? I think your intention is "no".

Please confirm my assumptions above. Depending on that we can try to address the wording, but I am not sure just deleting "original" from the previous text really helps.

> 	[JRE] It does seem to make sense to simplify it so that 
> you send all information in all provisional or final 
> responses (except 100). Just an example to help confirm 
> whether this simple rule makes sense:
> 	A proxy forks, sending requests with indices 1.1, 1.2 
> and 1.3. Then the 1.3 branch sends a response (provisional, 
> final) containing additional entry 1.3.1. In this case the 
> response that the proxy sends upstream would contain 1, 1.1, 
> 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 
> [MB2] The current approach is consistent with RFC 4244 
> whereby only the hi-entries for requests for which responses 
> have been received are included in the upstream response.  
[JRE] So you are saying that in my example above, indices 1.1 and 1.2 would not be sent upstream, because they have not responded? I am not asking for an explanation of how we got there - just asking what the model is intended to be.

> Again, it's hard for me to totally recall the logic, but I 
> think it was because at that point in time, you don't know 
> what will happen to that request - i.e., it's more misleading 
> than helpful.    We'd have to consider whether it would cause 
> an issue with backwards compatibility if we change this now. 
> IMHO, those entries only have value if you could accurately 
> tag that they were outstanding or had timed out rather than 
> infer that because they have no reason header means that the 
> retargeting entity has not yet received a response.
[JRE] You have brought to my attention something I missed before. When you put a Reason header field into an hi-entry, you now only convey that Reason header field in that hi-entry in the retargeted request downstream, but also in that same hi-entry when it gets sent upstream for any reason. So it begins to make sense to me now why you would exclude entries for requests that have not produced a response. However, this leads me to a couple of further questions:
1. According to 9.2, it is only failed requests that lead to retargeting that cause a Reason header field to be placed in their hi-entry, not failed requests that do not directly lead to retargeting. From what you say above, it seems that any failed request (3xx, 4xx, 5xx, 6xx) should cause a Reason header field to be placed into its hi-entry, even if that request does not lead to retargeting.
2. What about requests that so far have only produced a provisional response and have not been the cause of retargeting. Does that 1xx response code get put in the hi-entry as a Reason header field, and are those entries included in any upstream responses or retargeted requests that might be sent before the branch concerned issues a final response?

> Also, per 
> the comment above you would also have an hi-entry with an 
> index of  1.1.1 and that hi-entry would have a Reason header 
> field "escaped" in the hi-targeted-to-uri.  Whereas, neither 
> the 1.2 or 1.3.1 hi-entry would have a Reason header field in 
> the hi-targeted-to-uri. I don't see that to cause so much 
> confusion as there might be if it was 1.1., 1.2 and 1.3 
> requests had been issued at the same time and the only 
> response comes from 1.2, which has an hi-entry of 1.2.1. 
> Thus, the last hi-entry (i.e., 1.3) in the response isn't one 
> for which the request has received a response. [/MB2]
[JRE] I am lost on this one - I don't see the relevance of 1.1.1, which was not in my example. But anyway, if you answer the questions above, it should help.

John

---

From: Mary Barnes <[email-masked]>
Date: Tue, 22 Feb 2011 14:21:30 -0600

Hi John,

Responses inline below [MB3].

Mary.

> [JRE] I still don't see your response to this one.
[MB3] This goes back to core RFC 4244 behavior, although I think we might
have broken that as RFC 4244 only limited the UAS from not including HI in
responses rather than SIP intermediaries (although the behavior for an
intermediary wasn't totally clear in RFC 4244).   So, I can certainly see
your point.  And, making that change is consistent with other normative
behavior that we have changed (i.e., SHOULD add -> MUST add, not removing
headers for privacy, etc.).  It shouldn't break any current implementations
to make this change.  [/MB3]

> When I fork a request to several different targets, and when one of those
> branches returns a response which leads me to retarget, what is included in
> the retargeted request?
> 3. Clearly the entry for the request whose response caused me to retarget,
> and any additional entries in that response.
> 4. Do I include entries for other requests on other branches that have
> responded finally, and any additional entries in those responses, even
> though they have not led to retargeting? I think your intention is "yes".
> 5. Do I include entries for other requests on other branches that have
> responded provisionally, and any additional entries in those responses, even
> though they have not led to retargeting? I think your intention is "yes",
> but I am not certain (see also my comments further down concerning Reason
> header field - an answer of "no" might make more sense).
> 6. Do I include entries for other requests on other branches that have not
> yet responded? I think your intention is "no".
>
> Please confirm my assumptions above. Depending on that we can try to
> address the wording, but I am not sure just deleting "original" from the
> previous text really helps.
>
[MB3] Yes - the intent is exactly as you state above. [/MB3]

> [JRE] So you are saying that in my example above, indices 1.1 and 1.2 would
> not be sent upstream, because they have not responded? I am not asking for
> an explanation of how we got there - just asking what the model is intended
> to be.
>
[MB3] Correct.[/MB3]

> [JRE] You have brought to my attention something I missed before. When you
> put a Reason header field into an hi-entry, you now only convey that Reason
> header field in that hi-entry in the retargeted request downstream, but also
> in that same hi-entry when it gets sent upstream for any reason. So it
> begins to make sense to me now why you would exclude entries for requests
> that have not produced a response. However, this leads me to a couple of
> further questions:
> 1. According to 9.2, it is only failed requests that lead to retargeting
> that cause a Reason header field to be placed in their hi-entry, not failed
> requests that do not directly lead to retargeting. From what you say above,
> it seems that any failed request (3xx, 4xx, 5xx, 6xx) should cause a Reason
> header field to be placed into its hi-entry, even if that request does not
> lead to retargeting.

[MB3]  That is the intent - the Reason should be reflecting why the request
did not successfully terminate at the target (and thus why the request
might be retargeted or a response generated).    That all said, I think we
need more text around this as adding the Reason to the hi-entry is described
entirely in the context of retargeting and not specifically around sending
HI in responses.  So, I think we need to add some more text to the
definition of Reason.  And, I think we need to ensure that when we are
describing the Reason header that we also include the case in which the URI
that is being retargeted isn't the one with which the Reason is being
associated, as well as in cases where the Request was unsuccessful and a
response is generated.[/MB3]

2. What about requests that so far have only produced a provisional response
and have not been the cause of retargeting. Does that 1xx response code get
put in the hi-entry as a Reason header field, and are those entries included
in any upstream responses or retargeted requests that might be sent before
the branch concerned issues a final response?
[MB3] Yes, per my response above. [/MB3]

> [JRE] I am lost on this one - I don't see the relevance of 1.1.1, which was
> not in my example. But anyway, if you answer the questions above, it should
> help.
>
[MB3]  You had a 1.1.1 in your example under Comment 2.   Per my responses
above, I was highlighting that only the hi-entries for which responses have
been received are added (i.e., I changed your example such that 1.3 didn't
have a response and thus was trying to highlight that it would be confusing
to have a 1.3 entry since you really don't know what is going to happen with
that branch (i.e., it's not yet "complete"). [/MB3]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Feb 2011 16:14:29 -0500

(as individual)

I have been "loosely" following this.

What I am taking away from this discussion is that the bookkeeping and 
header flogging necessary to properly implement this, and then to 
interpret the results, are so extreme that its unlikely that it will be 
implemented correctly, if anyone even bothers to try.

What I fear most is that implementors will conclude that it is too hard 
to get right, but that they are required to support it, and so they will 
implement some approximation/subset/hack version of it.

In some respects this is like offer/answer, where there were a lot of 
loose ends, and closing them has brought a lot of complexity to 
something that was previously considered relatively simple. But o/a is a 
lot more important to sip than H-I is, so people are (I assume) more 
motivated. And I expect that nobody has tried to implement *all* of o/a 
as it is currently understood.

I don't have an answer here, just a concern. Maybe if I studied it all 
in excruciating detail, as if I were implementing it, I would feel 
better. But I doubt it.

	Thanks,
	Paul

On 2/22/2011 3:21 PM, Mary Barnes wrote:
> On Thu, Feb 17, 2011 at 3:09 PM, Elwell, John
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>      > From: Mary Barnes [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      >
>      >       Mary,
>      >
>      >       Thanks - see below:
>      >
>      >
>      > > From: Mary Barnes [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > > <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > >
>      > >
>      > >       Mary,
>      > >
> [MB3] This goes back to core RFC 4244 behavior, although I think we
> might have broken that as RFC 4244 only limited the UAS from not
> including HI in responses rather than SIP intermediaries (although the
> behavior for an intermediary wasn't totally clear in RFC 4244).   So, I
> can certainly see your point.  And, making that change is consistent
> with other normative behavior that we have changed (i.e., SHOULD add ->
> MUST add, not removing headers for privacy, etc.).  It shouldn't break
> any current implementations to make this change.  [/MB3]
>  > >
>     When I fork a request to several different targets, and when one of
>     those branches returns a response which leads me to retarget, what
>     is included in the retargeted request?
>     3. Clearly the entry for the request whose response caused me to
>     retarget, and any additional entries in that response.
>     4. Do I include entries for other requests on other branches that
>     have responded finally, and any additional entries in those
>     responses, even though they have not led to retargeting? I think
>     your intention is "yes".
>     5. Do I include entries for other requests on other branches that
>     have responded provisionally, and any additional entries in those
>     responses, even though they have not led to retargeting? I think
>     your intention is "yes", but I am not certain (see also my comments
>     further down concerning Reason header field - an answer of "no"
>     might make more sense).
>     6. Do I include entries for other requests on other branches that
>     have not yet responded? I think your intention is "no".
>
>     address the wording, but I am not sure just deleting "original" from
>     the previous text really helps.
>
>     [JRE] So you are saying that in my example above, indices 1.1 and
>     1.2 would not be sent upstream, because they have not responded? I
>     am not asking for an explanation of how we got there - just asking
>     what the model is intended to be.
>
> [MB3] Correct.[/MB3]
>
>
>     [JRE] You have brought to my attention something I missed before.
>     When you put a Reason header field into an hi-entry, you now only
>     convey that Reason header field in that hi-entry in the retargeted
>     request downstream, but also in that same hi-entry when it gets sent
>     upstream for any reason. So it begins to make sense to me now why
>     you would exclude entries for requests that have not produced a
>     response. However, this leads me to a couple of further questions:
>     1. According to 9.2, it is only failed requests that lead to
>     retargeting that cause a Reason header field to be placed in their
>     hi-entry, not failed requests that do not directly lead to
>     retargeting. From what you say above, it seems that any failed
>     request (3xx, 4xx, 5xx, 6xx) should cause a Reason header field to
>     be placed into its hi-entry, even if that request does not lead to
>     retargeting.
>
> [MB3]  That is the intent - the Reason should be reflecting why the
> request did not successfully terminate at the target (and thus why the
> request might be retargeted or a response generated).    That all said,
> I think we need more text around this as adding the Reason to the
> hi-entry is described entirely in the context of retargeting and not
> specifically around sending HI in responses.  So, I think we need to add
> some more text to the definition of Reason.  And, I think we need to
> ensure that when we are describing the Reason header that we also
> include the case in which the URI that is being retargeted isn't the one
> with which the Reason is being associated, as well as in cases where the
> Request was unsuccessful and a response is generated.[/MB3]
> 2. What about requests that so far have only produced a provisional
> response and have not been the cause of retargeting. Does that 1xx
> response code get put in the hi-entry as a Reason header field, and are
> those entries included in any upstream responses or retargeted requests
> that might be sent before the branch concerned issues a final response?
>     [JRE] I am lost on this one - I don't see the relevance of 1.1.1,
>     which was not in my example. But anyway, if you answer the questions
>     above, it should help.
>
> [MB3]  You had a 1.1.1 in your example under Comment 2.   Per my
> responses above, I was highlighting that only the hi-entries for which
> responses have been received are added (i.e., I changed your example
> such that 1.3 didn't have a response and thus was trying to highlight
> that it would be confusing to have a 1.3 entry since you really don't
> know what is going to happen with that branch (i.e., it's not yet
> "complete"). [/MB3]
>
>
>     John
>
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Mary Barnes <[email-masked]>
Date: Tue, 22 Feb 2011 15:23:57 -0600

The complexity of History-Info directly correlates with the complexity of
SIP itself, so there's not much that can be simplified.  The most complexity
is introduced in cases of parallel forking, which introduces many loose ends
as you note.  If we weren't dealing with parallel forking, I think alot of
the complexity is gone since the collection of the hi-entries happens in a
logical, known order. In the case of parallel forking, the indexing is how
the information can be logically sorted.

As I said early on, I have worked on this way too long to see how things can
be clarified.  I believe the wording as the capturing of the entries is
accurate (or nearly so), although it may not be in the most concise or
comprehensible form.  I would agree 100% that this document can not be
understood if it is read through only once - as I noted in another thread,
the layout of the material presents a chicken/egg situation.  Also, I have
to wonder if it wouldn't help to bring the detailed call flows back into
this document?

Regards,
Mary.

On Tue, Feb 22, 2011 at 3:14 PM, Paul Kyzivat <[email-masked]> wrote:

> header flogging necessary to properly implement this, and then to interpret
> the results, are so extreme that its unlikely that it will be implemented
> correctly, if anyone even bothers to try.
>
> What I fear most is that implementors will conclude that it is too hard to
> get right, but that they are required to support it, and so they will
> In some respects this is like offer/answer, where there were a lot of loose
> ends, and closing them has brought a lot of complexity to something that was
> previously considered relatively simple. But o/a is a lot more important to
> sip than H-I is, so people are (I assume) more motivated. And I expect that
> nobody has tried to implement *all* of o/a as it is currently understood.
>
> I don't have an answer here, just a concern. Maybe if I studied it all in
> excruciating detail, as if I were implementing it, I would feel better. But
> I doubt it.
>
>        Thanks,
>        Paul
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Feb 2011 18:06:32 -0500

(as individual)

IMO the complexity is intrinsic in the the goals that H-I is attempting 
to achieve. So I don't think additional wordsmithing will "solve" it. 
And many people (and organizations such as 3gpp) bought into those 
goals. So I think there is nothing to be done but push on and complete 
it, and let it be what it has become.

IMO the problem is in thinking that this complex set of information is 
the right solution to real needs, like deciding what voice mailbox to 
use for voicemail. There are other solutions to those problems.

	Thanks,
	Paul

On 2/22/2011 4:23 PM, Mary Barnes wrote:
> The complexity of History-Info directly correlates with the complexity
> of SIP itself, so there's not much that can be simplified.  The most
> complexity is introduced in cases of parallel forking, which introduces
> many loose ends as you note.  If we weren't dealing with parallel
> forking, I think alot of the complexity is gone since the collection of
> the hi-entries happens in a logical, known order. In the case of
> parallel forking, the indexing is how the information can be logically
> sorted.
> As I said early on, I have worked on this way too long to see how things
> can be clarified.  I believe the wording as the capturing of the entries
> is accurate (or nearly so), although it may not be in the most concise
> or comprehensible form.  I would agree 100% that this document can not
> be understood if it is read through only once - as I noted in another
> thread, the layout of the material presents a chicken/egg situation.
> Also, I have to wonder if it wouldn't help to bring the detailed call
> flows back into this document?
> Regards,
> Mary.
> On Tue, Feb 22, 2011 at 3:14 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     (as individual)
>
>     What I am taking away from this discussion is that the bookkeeping
>     and header flogging necessary to properly implement this, and then
>     to interpret the results, are so extreme that its unlikely that it
>     will be implemented correctly, if anyone even bothers to try.
>
>     What I fear most is that implementors will conclude that it is too
>     hard to get right, but that they are required to support it, and so
>     they will implement some approximation/subset/hack version of it.
>
>     In some respects this is like offer/answer, where there were a lot
>     of loose ends, and closing them has brought a lot of complexity to
>     something that was previously considered relatively simple. But o/a
>     is a lot more important to sip than H-I is, so people are (I assume)
>     more motivated. And I expect that nobody has tried to implement
>     *all* of o/a as it is currently understood.
>
>     I don't have an answer here, just a concern. Maybe if I studied it
>     all in excruciating detail, as if I were implementing it, I would
>     feel better. But I doubt it.
>
>             Thanks,
>             Paul
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>          >
>          >
>          >       Mary,
>          >
>          >       Thanks - see below:
>          >
>          >
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>          > >
>          > >
>          > >       Mary,
>          > >
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 22 Feb 2011 17:19:37 -0600

Hi Paul,

Your latter point is an excellent one and we are where we are because there
was a conscious decision (a decade ago) to define a general mechanism that
could be used by multiple applications as opposed to defining purpose built
mechanisms for various applications/services.  We have this discussion time
and again and as a result end up doing nothing in some cases, which is worse
that just picking one approach and following through with it.  Session ID is
a good example IMHO of whether it's best to define solutions for very
discrete problems (e.g,. debug) versus defining a solution that could be
applied to a variety of problem domains (e.g., logs, disaggregated media,
etc.).

I don't want to open up a long thread of discussion and agree that we just
need to move forward with this and complete it.

Thanks,
Mary.

On Tue, Feb 22, 2011 at 5:06 PM, Paul Kyzivat <[email-masked]> wrote:

> (as individual)
>
> IMO the complexity is intrinsic in the the goals that H-I is attempting to
> achieve. So I don't think additional wordsmithing will "solve" it. And many
> people (and organizations such as 3gpp) bought into those goals. So I think
> there is nothing to be done but push on and complete it, and let it be what
> it has become.
>
> IMO the problem is in thinking that this complex set of information is the
> right solution to real needs, like deciding what voice mailbox to use for
> voicemail. There are other solutions to those problems.
>
>        Thanks,
>        Paul
>
>