Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis

[Mary Barnes <[e-mail]>]

John,

I've done the same. A couple responses inline below [MB2].

Thanks,
Mary.

On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John
<[e-mail]> wrote:
> Mary,
>
> I have responded below, stripping out the stuff where I have nothing further to add.
>
<snip>
>> > 2. It nearly always uses the term "header" rather than
>> "header field", although never, as far as I know, meaning the
>> entire SIP header.
>> [MB] I'm not sure that I fully understand the concern. Can you point
>> out a specific sentence or section of concern?  The term "header" is
>> used when it is referring to the History-Info header field, but that
>> is done in other documents as well.  In general, I think it's
>> understood that it's referring to the header field when it's
>> qualified. Perhaps you're referring to places where it is not
>> qualified?   The term hi-entry is used, as well.
>> [/MB]
> [JRE] I have explained in more detail in my comments on -02.
[MB2] I've responded to that in my subsequent response to your comments. [/MB2]
>
> <snip/>

>> >
>> > 18. Section 4.2.2:
>> > "the UAS MUST
>> >   include any History-Info received in the request  in the
>> subsequent
>> >   response"
>> > Does this include 100 responses?
>> [MB] I would think so. Can you think of a reason why it shouldn't?  I>> would think it could be useful for debug. [/MB]
> [JRE] The 100 response typically only travels back a single hop, so the benefit of H-I in a 100 is marginal. Also some implementations might send back a 100 response quite early during processing, perhaps even before they decide whether to act as a proxy, a UAS or a redirect, so knowing how to populate H-I in a 100 might be difficult.
[MB2] If it has no additional hi-entries, then there is nothing
additional to send back, so I don't think it hurts anything - I would
agree that in most cases it's of marginal value. We can include it as
an exception in that sentence if you would prefer, although per the
next comment, it seems that you are okay with leaving it as is.
[/MB2]
>
> <snip/>
>> >

>> >
>> > 26. Section 5.2:
>> > "A proxy that receives a request with the "histinfo" option
>> tag in the
>> >   Supported header, SHOULD forward captured History-Info in
>> subsequent,
>> >   provisional , and final responses "
>> > Does this include 100 responses?
>> [MB] That's the implication of "provisional" per RFC 3261. [/MB]
> [JRE] I am doubtful about the usefulness of 100. However, it is probably fairly academic, since 100 will probably have been sent earlier. A proxy is unlikely to send a 100 after receiving a provisional response from a downstream entity.
>
>> >
>> > 27. Section 5.2:
>> > "A proxy MAY anonymize any hi-entry whose domain corresponds to a
>> >   domain for which it is responsible (as per [RFC3323 ])."
>> > I don't think RFC 3323 tells me how to anonymize an hi-entry.
>> [MB]  RFC 3323 discusses anonymization and the role of an anonymizer,
>> etc. So, I'm not clear on your concern. [/MB]
> [JRE] I guess if we talked about anonymizing the URI in the hi-target-to-uri it would be clearer.
[MB2] That's fine...I'll make it explicit that it's the
hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2]
>
> <snip/>
>
>
> John