Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored

[Adam Roach <[e-mail]>]

Sure -- my suggestion was one for clarification. If 3GPP does, in fact, 
intend to allow the header field in mid-dialog  messages, then my 
comment doesn't apply.

But if they *do* intend to allow the field mid-dialog, I'm curious about 
why it's forbidden in the current list of methods: save for some obscure 
corner cases, all of the methods called out by name are sent mid-dialog, 
and none of the un-named methods are.

Either way, it's just a suggestion. The hard block here is in the ACK 
handling that I pointed out.

/a

On 4/27/16 08:01, Christer Holmberg wrote:
> Hi,
>
> One more thing:
>
> I guess we could also change ³all responses² to ³all non-100 responses²,
> as 100 responses are also hop-to-hop (similar to ACKs triggered by non-2xx
> responses).
>
> Regards,
>
> Christer
>
>
> On 25/04/16 14:30, "Christer Holmberg" <[e-mail]>
> wrote:
>
>> Hi Adam,
>>
>> Are you ok with my suggested way forward?
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> On 21/04/16 22:43, "Christer Holmberg" <[e-mail]>
>> wrote:
>>
>>> Hi Adam,
>>>
>>> ....
>>>
>>>>> One additional review note that does not affect my expert review
>>>>> (treat it as a last-call comment):
>>>>>
>>>>>
>>>>>       Add statement that the P-Visited-Network-ID header field cannot
>>>>>       appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods.
>>>>>
>>>>> It seems to me that it would be significantly more future proof to
>>>>> phase this as "...cannot appear in mid-dialog requests," as that
>>>>> appears to be the intention. The revised text then becomes something
>>>>> like: "The P-Visited-Network-ID header
>>>>> field can appear in all SIP methods except ACK and CANCEL; however, it
>>>>> cannot be sent in >any mid-dialog requests."
>>>> Seems reasonable, but I'll verify with my 3GPP delegates.
>>> I had a closer look at this, and I don't think we can forbid usage in all
>>> mid-dialog requests.
>>>
>>> For example, the header field is allowed in OPTIONS, that can be sent
>>> in-dialog.
>>>
>>> Also, the header field is allowed in REFER, and RFC 7614 defines a
>>> mechanism that allows in-dialog REFERs.
>>>
>>> re-INVITE is also tricky. The header field is generally allowed in INVITE
>>> requests, but there is no text explicitly disallowing it in re-INVITEs.
>>>
>>> Whether it makes sense to include the header field in the methods above I
>>> don't know (3GPP does allow them), but as the purpose is only to align
>>> 7315 with 3455 I'd suggest we keep the text as it is.
>>>
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 3/7/16 14:08, A. Jean Mahoney wrote:
>>> Since this draft updates RFC 7315, which required expert review of its
>>> header fields, Adam Roach will be conducting an expert review of this
>>> draft according to the guidance given in RFC 5727.
>>>
>>> Thanks,
>>>
>>> Jean
>>>
>>>
>>> On 3/7/16 9:33 AM, Mary Barnes wrote:
>>>
>>> Hi folks,
>>>
>>> This document has been proposed to be progressed as AD sponsored:
>>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-updates/
>>> The document has been carefully reviewed and it is now ready to move
>>> forward - Jean Mahoney is the shepherd.
>>>
>>> I don't anticipate anyone would have concerns about this decision, given
>>> that's how RFC 7315 was progressed and this update has actually been much
>>> more carefully reviewed.  However, f anyone has any final comments,
>>> please post no later than Friday, March 11th, 2016.  Note, that you will
>>> also still have IETF LC to provide any comments.
>>>
>>> Regards,
>>> Mary.
>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch