I'm very support of this draft and think it should move forward but I have a 
NIT to pick with it.

It says the ABNF in 3261 is incorrect and this one corrects it. I don't believe 
that is correct. I believe the ABNF in this draft is more specific than the one 
in 3261 but they are both correct. I think this is an important distinction 
that should be corrected in the draft and I will try and motivate why. 

The ABNF is what helps an implementor know what sort of parse they need to 
write such that it can successfully parse over unknown extensions. It also 
constrain what future syntax extensions can use. There is a constant pressure 
to make it explicitly represent the current semantic limitations of the 
protocol. But the ABNF is not what defines the protocol, the text in the RFC 
does that. For example, most ABNF that have a port number would allow a number 
that was greater than 2^16. We could write ABNF that limited the port number to 
a 16 bit integer but typically we don't and instead define the port in the 
text. 

As far as I can tell, there is nothing "wrong" with the ABNF in 3261, it is 
just less specific than we would like and this new ABNF is more specific will 
limit future RFC and extensions to conform with the range of syntaxes allowed 
by this extortion. Because of this I don't believe this should "update" 3261. 
Every time we have an "update" to 3261 vendors have to go thought a huge 
exercise and discussion with customers if their products are still compliant 
etc. In the case of this draft that would be a huge waste of time as clearly no 
code is changed by this. 

Cullen <in my individual contributor role>



On Mar 5, 2010, at 4:30 PM, The IESG wrote:

> The IESG has received a request from the Session Initiation Protocol WG 
> (sip) to consider the following document:
> 
> - 'Essential correction for IPv6 ABNF and URI comparison in RFC3261 '
>   <draft-ietf-sip-ipv6-abnf-fix-04.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2010-03-19. Exceptionally, 
> comments may be sent to i...@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-04.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16959&rfc_flag=0
> 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-implement...@cs.columbia.edu for questions on how to develop a SIP 
> implementation.
> Use dispa...@ietf.org for new developments on the application of sip.
> Use sipc...@ietf.org for issues related to maintenance of the core SIP 
> specifications.


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to