Hi Robert, On 04/16/2013 10:40 AM, Robert Sparks wrote: > Suresh - > > One more comment (trimming heavily) > > On 4/16/13 3:40 AM, Iñaki Baz Castillo wrote: >> >>> * Section 5.2 >>> >>> The updated ABNF provided in section 5.2.1. is confusing. e.g. RFC4168 >>> specifies the entire transport rule as follows >>> >>> transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" >>> / other-transport >>> >>> while this document just uses an incremental alternative and calls it an >>> updated rule. I would have expected an *updated* rule to say >>> >>> transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" / "WS" >>> / "WSS" / other-transport >> There was a long discussion in SIPCORE WG about this subject and >> finally it was chosen to use the incremental alternative (so the >> updated ABNF would be also longer in the future when new SIP >> transports are defined). >> >> Do you consider anyhow that using the fully updated rule is required? >> >> > Suresh - > > The issue is that we have many header fields where more than one > document may > add a token. Restating the full production each time has proven > problematic, > particularly when more than one draft that proposes adding a token is in > flight at the > same time. Instead, we're adopting a consistent approach of using the > the incremental > alternative rule to add tokens and IANA registries to make it easy to > find the > tokens that have been documented to date.
That sounds like a good plan. I was more concerned with the wording that calls this an "updated rule" and the fact that the title of Section 5.2 "Updates to RFC3261" that implies the incremental rule could be interpreted to add to the rule specified in RFC3261 and lose other additions since (in this case losing TLS-SCTP). If you have a plan in place with IANA to take care of this I am fine with this approach. Thanks Suresh _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
