Re: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

Hi,

Any comment on this?

RFC 3261 does say:

"The relative order of header field rows with the same field name is important."

However, I can’t find any generic rule how  header field rows with the same name are added to a SIP message. Record-Route, Route etc all have header field specific rules (which often are the identical).

Regards,

Christer

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> on behalf of Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Date: Saturday 13 January 2018 at 11:30
To: "adam@nostrum.com<mailto:adam@nostrum.com>" <adam@nostrum.com<mailto:adam@nostrum.com>>, IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>
Subject: Re: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

Hi,

One more comment on this.

No matter if one uses comma separation within a single Identity header field, or multiple Identity header fields, the spec doesn’t say anything about the semantics of the order of the header fields.

For example, in SIP the order of Record-Route, Route, Via etc matters, because it impacts how a SIP message is routed.

My first thought was that it doesn’t really matter in which order Identity header fields are listed in a SIP message, so we don’t need to say anything (in addition to the fact that multiple header fields are allowed).

But, when I read the divert extension slides from Singapore, it says the following:

     “An Identity header with “div” always points to some prior Identity header”

The word *prior* seem to indicate that the order of header fields DOES matter (as the Identity header field does not contain any “sequence number,” or similar mechanism for ordering them).

So, even if divert would use a single Identity header field, shouldn’t 4474bis specify how Identity headers are added to a SIP message?

Otherwise we could end up with a situation with vendor A sending:

Identity: A
Identity: B

…and vendor B sending:

Identity: B
Identity: A

In some case the order may not matter, in some cases it may.

Or?

Regards,

Christer

From: Adam Roach [mailto:adam@nostrum.com]
Sent: 09 January 2018 00:05
To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>
Subject: Re: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

[as responsible AD]

Christer --

Thanks for looking closely at 4474bis and offering up your comments. Based on the current state of things, I don't think changes are warranted at this time.

This document is in AUTH48 with sign-offs from all but one author. While discovery of a catastrophic error would be enough to warrant additional working-group crafting on the document, I don't see anything here that is catastrophic. The multiple-header issue you describe is a bit confusing, but that appears to be a flaw in RFC3261 more than this document. Importantly, the section of 3261 you cite is followed by:

   The exceptions

   to this rule are the WWW-Authenticate, Authorization, Proxy-

   Authenticate, and Proxy-Authorization header fields.  Multiple header

   field rows with these names MAY be present in a message, but since

   their grammar does not follow the general form listed in Section 7.3<https://tools.ietf.org/html/rfc3261#section-7.3>,

   they MUST NOT be combined into a single header field row.

This, combined with the fact that the syntax of "Identity" *also* doesn't follow the general form listed in RFC 3261 section 7.3, means that the "...MAY... if and only if..." construct you cite also doesn't apply to it. It might have been cleaner to indicate that "Identity" is added to the list of exceptions in section 7.3.1 of RFC 3261, but this seems to be a lack of tidiness rather than a critical flaw in the document.

I will note that the decision not to allow comma separation appears to have been intentional [1], and was mentioned as recently as last June on the mailing list [2]. In that light, I believe that your request would functionally be asking to reverse prior working group consensus rather than fixing an error. We are well past the point of revisiting past working group decisions on this document.

/a

____
[1] Although I can't find the corresponding minutes or email, I have a vague recollection of discussions about which syntax would be more likely to be compatible with exiting RFC4474 implementations, with the current syntax reflecting the outcome of those discussions.

[2] https://mailarchive.ietf.org/arch/msg/stir/tAhE7jD6OWTlGHO-MLQavpODm1s

On 1/8/18 09:23, Christer Holmberg wrote:
Hi,

Related to my issue below, I think it would be good to show a complete example with two Identity header fields in section 4.1 of draft-ietf-stir-passport-divert-01.

Regards,

Christer

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> on behalf of Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Date: Thursday 4 January 2018 at 12:10
To: IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>
Subject: Re: [stir] draft-ietf-stir-rfc4474bis-16: Syntax question

Is it still possible to fix this in the document, or do we file an errata once the RFC has been published?

Regards,

Christer

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> on behalf of Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Date: Wednesday 3 January 2018 at 20:57
To: IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>
Subject: [stir] draft-ietf-stir-rfc4474bis-16: Syntax question

Hi,

Section 4 says:

   “Note that unlike the prior specification
   in RFC4474, the Identity header field is now allowed to appear more
   than one time in a SIP request.  The revised grammar for the Identity
   header field builds on the ABNF [RFC5234] in RFC 3261 [RFC3261]
   Section 25.  It is as follows:

      Identity = "Identity" HCOLON signed-identity-digest SEMI
      ident-info *( SEMI ident-info-params )
      …”

However, that syntax does NOT allow multiple Identity header fields, according to the rules in RFC 3261:

   “Multiple header field rows with the same field-name MAY be present in
   a message if and only if the entire field-value for that header field
   is defined as a comma-separated list”

It should be something like:

     Identity = "Identity" HCOLON signed-identity * (COMMA signed-identity)
     signed-identity = signed-identity-digest SEMI identi-info * (SEMI ident-info-params)
     …”

Or, misunderstood I have?

Regards,

Christer

_______________________________________________

stir mailing list

stir@ietf.org<mailto:stir@ietf.org>

https://www.ietf.org/mailman/listinfo/stir