Subject: RE: NITs I found while reading the SIP spec

From: Yaron Goland <[email-masked]>
Date: Sat, 2 May 1998 19:46:12 -0700

> > Your hostnumber production does not support IPv6
> 
> Do you have an existing production?
> 

No, but I'm sure the IPv6 working group can help you. You will need to fix
this in order to survive last call.

> The only issue I see is that:
> 
> From: John Doe <[email-masked]>
> 
> would become
> 
> From: John Doe <sip:[email-masked]>
> 

Since this header is sent at the protocol level, rather than the user level,
I don't think the issue is a major one. For example, a SIP based telephone
program could easily accept [email-masked] and know to change that to
sip:[email-masked] on the wire.

> > 5.7 6.39 Warning
> > 
> > The BNF for the warn-code is 2DIGIT but you use a four 
> digit with a "."
> > warning format because of your desire to use 606 warnings. 
> I would suggest
> > that this is an inappropriate use of the warning header. 
> Instead your should
> > introduce new 6xx codes to cover what you now call 
> warnings. Regardless of
> > the outcome, either the examples must change or the BNF 
> production for
> > warn-code in 6.39 must be changed.
> 
> The idea was to be able to provide several warnings in the 
> same message,
> which is difficult to do with status codes. Suggestions?
> 

I addressed this issue in section 3.3.6 of my original comments. The purpose
of section 5.7 was to say that regardless of what resolution you choose,
whether to be HTTP compliant or not, your BNF and your examples are
inconsistent with each other and must be changed.

> Henning

				Yaron

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 03 May 1998 14:19:22 -0400

> this in order to survive last call.
Given the wording in draft-fielding-uri-syntax-02.txt:

"Note: A suitable representation for including a literal IPv6
      address as the host part of a URL is desired, but has not yet
      been determined or implemented in practice."

I'm very reluctant to jump in here, given that having a specification
that contradicts the new URL RFC is worse than leaving this open for
now. Based on the RTSP experience, anything that is not an RFC at this
moment cannot make it into the SIP spec for the "proposed" round. This,
for example, precludes any use of the HTTP equivalent of "Require" - we
got badly burned last time (with RTSP) when we assumed that the HTTP
side would be ready in time.

Henning