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

[Christer Holmberg <[e-mail]>]

Hi,

...

>> 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.

The purpose of this task was to fix misalignments between 3455 and 7315, and incorporate new 3GPP requirements - which are described in section 3.3 - and update the existing text (see below) in 7315 based on that.

Old text:

   The P-Associated-URI header field can appear in SIP REGISTER method
   and 2xx resonses.  The P-Called-Party-ID header field can appear in
   SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all
   responses.  The P-Visited-Network-ID header field can appear in all
   SIP methods except ACK, BYE, and CANCEL and all responses. The
   P-Access-Network-Info header field can appear in all SIP methods
   except ACK and CANCEL.  The P-Charging-Vector header field can appear
   in all SIP methods except CANCEL.  The P-Charging-Function-Addresses
   header field can appear in all SIP methods except ACK and CANCEL.


Regards,

Christer
 


>> 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-u
>>>>> pdate
>>>>> 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
>

_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch