Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis)

On 11/2/2010 4:31 PM, Elwell, John wrote:
> So the remaining issue from this thread concerns whether to mandate History-Info in a all provisional responses or just non-100 provisional responses (subject to presence of the option tag in the request). Given that 100 tends to be generated differently from other provisional responses, and given the marginal use of H-I in 100 responses, I would prefer either to omit H-I from 100 responses or use MAY. I don't have a strong opinion, but perhaps others have a view.

Requiring (even permitting) H-I in 100 responses is a *terrible* idea.

I don't see why you would need H-I in *any* provisional responses (with 
the possible exception of 199.)

(Disclaimer - I have not read all the discussion on this subject.)

	Thanks,
	Paul

> John
>
>
>> -----Original Message-----
>> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
>> Sent: 02 November 2010 19:51
>> To: Elwell, John
>> Cc: sipcore@ietf.org
>> Subject: Re: [sipcore] REMINDER: Re: WGLC:
>> draft-ietf-sipcore-rfc4244bis
>>
>> 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
>> <john.elwell@siemens-enterprise.com>  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
>>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>