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

[Paul Kyzivat <[e-mail]>]

On 4/27/16 11:07 AM, Christer Holmberg wrote:
> Hi,
>
>> 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.
>
> OPTIONS, BYE, REFER (with RFC7615) and re-INVITE can be sent in-dialog.

and MESSAGE.

> I can’t give an answer here and now why the list looks like it does, but
> this is how it’s specified in 3GPP :)
>
>> Either way, it's just a suggestion. The hard block here is in the ACK
>> handling that I pointed out.
>
> Based on your comments, the new text would now say:
>
>    "The P-Associated-URI header field can appear in SIP REGISTER
>    2xx responses. The P-Called-Party-ID header field can appear in
>    SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.
>    The P-Visited-Network-ID header field can appear in all SIP methods
>    except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The
>    P-Access-Network-Info header field can appear in all SIP methods
>    and non-100 responses, except in CANCEL methods, CANCEL responses
>    and ACK methods triggered by non-2xx responses. The P-Charging-Vector
>    header field can appear in all SIP methods and non-100 responses,
>    except in CANCEL methods, CANCEL responses and ACK methods triggered
>    by non-2xx responses. The P-Charging-Function-Addresses header field
>    can appear in all SIP methods and non-100 responses, except in ACK
>    and CANCEL methods and CANCEL responses.”

These rules seem very arbitrary, without any obvious rationale - why are 
the rules different for the four different header fields?

I can see that there might be a rationale, based on need during dialog 
establishment or maybe just *call* establishment. But if so, I would 
think a generic way of describing the rule would work better than 
enumeration.

So basically, if the rationale for the difference is stated first, then 
it ought to make clear what messages are appropriate. When there are 
just different sets of enumerations without explanation it invites 
debate over the particular messages included.

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
>
>
>
>
>
>>
>> /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-update
>>>>> s/
>>>>> 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
>>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>