Subject: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184)

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Nov 2017 08:52:00 +0800

Hi, 

Does anyone in sipcore have thoughts on this? 

Thanks,

Ben.

Begin forwarded message:

> From: RFC Errata System <[email-masked]>
> Date: November 16, 2017 at 10:20:38 AM GMT+8
> To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: [Technical Errata Reported] RFC3323 (5184)
> 
> The following errata report has been submitted for RFC3323,
> "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5184
> 
> --------------------------------------
> Type: Technical
> Reported by: DONG O YI <[email-masked]>
> 
> Section: 4.2 Expre...
> 
> Original Text
> -------------
> Privacy-hdr  =  "Privacy" HCOLON priv-value *(";" priv-value)
> 
> 
> Corrected Text
> --------------
> Privacy-hdr  =  "Privacy" HCOLON priv-value *("," priv-value)
> 
> 
> Notes
> -----
> RFC3261 says, 
> 
> Specifically, any SIP header whose grammar is of the form
> 
>      header  =  "header-name" HCOLON header-value *(COMMA header-value)
> 
>   allows for combining header fields of the same name into a comma-
>   separated list.
> 
> So, RFC3323 conflicts RFC3261.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC3323 (draft-ietf-sip-privacy-general-01)
> --------------------------------------
> Title               : A Privacy Mechanism for the Session Initiation Protocol (SIP)
> Publication Date    : November 2002
> Author(s)           : J. Peterson
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Nov 2017 01:47:22 +0000

Hi,

I am looking into this.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: 17 November 2017 02:52
To: [email-masked]
Subject: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184)

Hi,

Thanks,

Ben.

Begin forwarded message:
From: RFC Errata System <[email-masked]<mailto:[email-masked]>>
Date: November 16, 2017 at 10:20:38 AM GMT+8
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: [Technical Errata Reported] RFC3323 (5184)
The following errata report has been submitted for RFC3323,
"A Privacy Mechanism for the Session Initiation Protocol (SIP)".

--------------------------------------
Type: Technical
Reported by: DONG O YI <[email-masked]<mailto:[email-masked]>>

Section: 4.2 Expre...

Original Text
-------------

Corrected Text
--------------

Notes
-----
RFC3261 says,

Instructions:
-------------

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 17 Nov 2017 01:52:50 +0000

RFC3323 did not manage multiple values for the Privacy header in the way that passage in RFC3261 explicitly allows. But I don't read RFC3261 as requiring that all headers that admit of multiple values MUST use comma separation rather than semicolon separation. It might be a one-off but in what sense is this a bug?

Jon Peterson
Neustar, Inc.

On Nov 17, 2017, at 8:52 AM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks,

Ben.

Begin forwarded message:

Section: 4.2 Expre...

Original Text
-------------

Corrected Text
--------------

Notes
-----
RFC3261 says,

Instructions:
-------------

--------------------------------------
RFC3323 (draft-ietf-sip-privacy-general-01)
--------------------------------------
Title               : A Privacy Mechanism for the Session Initiation Protocol (SIP)
Publication Date    : November 2002
Author(s)           : J. Peterson
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Nov 2017 00:58:49 -0500

> Does anyone in sipcore have thoughts on this?

Yes. Inline.

> Thanks,
> 
> Ben.
> 
> Begin forwarded message:
> 
>> *From:* RFC Errata System <[email-masked] 
>> <mailto:[email-masked]>>
>> *Date:* November 16, 2017 at 10:20:38 AM GMT+8
>> *To:* [email-masked] <mailto:[email-masked]>, 
>> [email-masked] <mailto:[email-masked]>, [email-masked] 
>> <mailto:[email-masked]>, [email-masked] 
>> <mailto:[email-masked]>, [email-masked] 
>> <mailto:[email-masked]>, [email-masked] 
>> <mailto:[email-masked]>
>> *Cc:* [email-masked] <mailto:[email-masked]>, 
>> [email-masked] <mailto:[email-masked]>
>> *Subject:* *[Technical Errata Reported] RFC3323 (5184)*
>>
>> Reported by: DONG O YI <[email-masked] <mailto:[email-masked]>>
>>
>> Section: 4.2 Expre...
>>
>> Original Text
>> -------------

Well...

ISTM that the syntax *ought* to have been:

Privacy-hdr  =  "Privacy" HCOLON priv-value *(COMMA priv-value)

for stylistic consistency with other similar header fields. But as 
written it doesn't *conflict* with the referenced section - it simply 
doesn't qualify as an example of that.

And if it was explicitly intended to use semicolon (hence following the 
typical parameter syntax) then it *should* have been:

Privacy-hdr  =  "Privacy" HCOLON priv-value *(SEMI priv-value)

BUT given the late date that this has come to light much concern must be 
paid to what has been deployed. I looked (not very hard) for published 
examples that have multiple privacy values, but didn't find any.

	Thanks,
	Paul

> [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Nov 2017 09:52:36 +0000

Hi,

...

> BUT given the late date that this has come to light much concern must be paid to what has been 
> deployed. I looked (not very hard) for published examples that have multiple privacy values, but didn't find any.

I believe there are cases with multiple values. It's a little difficult for me to look for them while in Singapore, but once I'm back in office it will be easier.

Regards,

Christer

---

From: <[email-masked]>
Date: Fri, 17 Nov 2017 10:10:32 +0000

Hi,
I have asked my guys to forward me how we have the done the implementation.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von Christer
> Holmberg
> Gesendet: Freitag, 17. November 2017 10:53
> An: Paul Kyzivat <[email-masked]>; [email-masked]
> Betreff: Re: [sipcore] Fwd: [Technical Errata Reported] RFC3323 (5184)
> 
> Hi,
> 
> ...
> 
> > BUT given the late date that this has come to light much concern must
> > be paid to what has been deployed. I looked (not very hard) for published
> I believe there are cases with multiple values. It's a little difficult for me to look
> for them while in Singapore, but once I'm back in office it will be easier.
> 
> Regards,
> 
> Christer
>

---

From: <[email-masked]>
Date: Fri, 17 Nov 2017 10:31:07 +0000

Hi,
it was faster than expected.
So we are separating with semicolon.
Like:
Privacy: header;id;user

So I would not propose to change anything.
It will not be backwards compatible. And I assume we will get in trouble when:
Privacy: header,id,user appear.

PS: It is a implementation from Christer's company.

Best Regards

Roland
> Von: sipcore [mailto:[email-masked]] Im Auftrag von Jesske, Roland
> Gesendet: Freitag, 17. November 2017 11:11
> An: [email-masked]; [email-masked]; [email-masked]
> > > BUT given the late date that this has come to light much concern
> > > must be paid to what has been deployed. I looked (not very hard) for
> > > published
> > I believe there are cases with multiple values. It's a little
> > difficult for me to look for them while in Singapore, but once I'm back in
> office it will be easier.
> >
> > Regards,
> >
> > Christer
> >

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 17 Nov 2017 21:54:53 -0500

>> Original Text

My suspicion is that the syntax with semicolon was chosen specifically
to prevent the rule for combining header fields from being applicable.
This ensures that if the UA sends a single Privacy header with multiple
values, no intermediary can split it into multiple Privacy headers.
(The text only speaks of a single Privacy header, never multiple ones.)

But as Paul says, (1) it should be SEMI and (2) we must pay attention to
what has been deployed.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Nov 2017 05:40:11 +0000

Hi,

>PS: It is a implementation from Christer's company.

Luckily I got the same feedback from our product people :)

So, I don't think we should change anything.

I don't even think the intention ever was to allow multiple instances of the Privacy header field. What would the semantics of having multiple header field instances be? 

For headers where we DO allow multiple instances (whether the header field values are comma separated within a single header instance, or in separate header instances) there is clear semantics for that. E.g., Contact, Record-Route, Route, Via etc.

Regards,

Christer

> > Von: sipcore [mailto:[email-masked]] Im Auftrag von 
> > Christer Holmberg
> > > must be paid to what has been deployed. I looked (not very hard) 
> > > for published

---

From: Dean Willis <[email-masked]>
Date: Sat, 18 Nov 2017 10:16:41 -0600

I concur with this set of arguments.

Not valid.

On Nov 17, 2017 23:40, "Christer Holmberg" <[email-masked]>
wrote:

> I don't even think the intention ever was to allow multiple instances of
> the Privacy header field. What would the semantics of having multiple
> header field instances be?
>
> For headers where we DO allow multiple instances (whether the header field
> values are comma separated within a single header instance, or in separate
> header instances) there is clear semantics for that. E.g., Contact,
> Record-Route, Route, Via etc.
>
> Regards,
>
> Christer
>
>