Subject: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 02 Dec 2007 23:29:45 -0500

may define the wrong thing so as to minimize change. In particular I 
don't like alternative 2 and think we probably need a new response code.

The other big question is, is it worth defining a new response code now, 
and then later on basically updating it with the right overload handling 
behavior, or do it all at once. I think that requires some discussion.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 03 Dec 2007 09:12:37 -0600

Jonathan Rosenberg wrote:
> This looks like a good document and definitely something that is in the 
> category of an essential correction. My only comment is that I think 
> there is also an issue with v6 URI equality that we need to fix, and may 
> as well wrap that into a single v6 essential correction.

Jonathan: Can you elaborate on the v6 URI equality fix?  Are you
referring to the one Brett raised about the equivalence of
sip:[::ffff:192.0.2.128] and sip:[::ffff:c000:280]?

If so, we have decided to include it in this v6 essential correction.

> Nits:
> 
> Missing period at end of abstract

Will add in.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Dec 2007 12:43:24 -0500

Yes, that was the one I was talking about.

-Jonathan R.

Vijay K. Gurbani wrote:
>> This looks like a good document and definitely something that is in 
>> the category of an essential correction. My only comment is that I 
>> think there is also an issue with v6 URI equality that we need to fix, 
>> and may as well wrap that into a single v6 essential correction.
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 03 Dec 2007 11:55:16 -0600

> Yes, that was the one I was talking about.

OK -- then we have it covered.  I have had a conversation
with Brett and Gonzalo and we decided to include v6 URI
equality clarification in  the next release of the draft,
post Vancouver.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 03 Dec 2007 13:29:37 -0600

Brian E Carpenter wrote:
> Ack. What about the generic equivalence between :: and the zeros that
> it elides?

We should also include that as a point in the discussion.

After Vancouver, Brett and I will sent out some text to the WG
for further comments on v6 equality clarifications.

Thanks,

- vijay

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Dec 2007 08:08:36 +1300

Regards
    Brian Carpenter
    University of Auckland

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 3 Dec 2007 18:42:53 -0500

> What about the generic equivalence between :: and 
> the zeros that it elides?

As Vijay mentioned, enhancements concerning IPv6 (and IPv4) address
equivalency will be added within the next version of the draft.

The initial focus will likely be on the impacts of the variations
presented within rfc4291 sections 2.2 and 2.5.5.  The variations
presented within section 2.2 (such as your question) should be
considered equivalent from a SIP perspective.  However concerning things
like To/From sip-uri's host, I assume that there will currently be poor
interoperability if devices adjust things per section 2.2's flexibility
(beyond hex case) within a transaction or dialog.

I haven't received any feedback concerning impacts of section 2.5.5.
However I assume that they should not be considered equivalent to their
IPv4 addresses from a SIP perspective.  And other IPv6 addresses are
also not equivalent to their IPv4 counterpart; for instance "::1" does
not equal "127.0.0.1".

For prior threads... the following were my initial questions posted to
sip-implementors.  The first reflects questions related to rfc4291
section 2.2.  The second reflects questions related to section 2.5.5.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-October/01
7678.html

https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-October/01
7692.html

---

From: [email-masked]
Date: Tue, 4 Dec 2007 23:24:48 -0500

From: "Brett Tate" <[email-masked]>

   However concerning things
   like To/From sip-uri's host, I assume that there will currently be poor
   interoperability if devices adjust things per section 2.2's flexibility
   (beyond hex case) within a transaction or dialog.

To and From headers shouldn't be a problem because applications really
shouldn't be comparing them; they should be treated as comments.
IIRC, there is some circumstance during registration where URI
equivalence is important, though.

That makes sense to me.

Dale

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 5 Dec 2007 12:49:41 -0500

> > However concerning things like To/From sip-uri's host, 
> > I assume that there will currently be poor 
> > interoperability if devices adjust things per 
> > section 2.2's flexibility (beyond hex case) 
> > within a transaction or dialog.
> 
> To and From headers shouldn't be a problem because 
> applications really shouldn't be comparing them; they 
> should be treated as comments.
> IIRC, there is some circumstance during registration 
> where URI equivalence is important, though.

RFC 3261 still requires the To/From uri's to not change.  However I
agree that it won't be a problem if vendors have adjusted/deployed their
implementations based upon rfc3261's comment that such a requirement is
expected to be deprecated in the future or have accommodated the IPv6
address representation flexibility.

---

From: "Jane Jiang" <[email-masked]>
Date: Wed, 5 Dec 2007 19:57:52 -0800

Hi all,

I guess the purpose of this discussion is about this particular draft,
which intends to correct some mistakes existing in some RFCs.

I am wondering if you will want to discuss about the impacts of mapping
between IPv6 address and IPv4 address?

I feel like if we simply try to match the two from each other, we will
not be able to maintain the original design beauties behind each address
structure.  Correct me if I am wrong.

Best regards,
Jane D. Jiang

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2007 9:50 AM
To: [email-masked]; [email-masked]
Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00

> > However concerning things like To/From sip-uri's host, I assume that

> > there will currently be poor interoperability if devices adjust 
> > things per section 2.2's flexibility (beyond hex case) within a 
> > transaction or dialog.
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 6 Dec 2007 13:26:03 -0500

> I guess the purpose of this discussion is about this 
> particular draft, which intends to correct some mistakes 
> existing in some RFCs.

Yes; the draft is expanding beyond the current ABNF fix to also correct
or more clearly document other IPv6 areas of rfc3261.

> I am wondering if you will want to discuss about the impacts 
> of mapping between IPv6 address and IPv4 address?

I'm not sure which aspect of mapping you are mentioning.
Draft-ietf-sipping-v6-transition and
draft-ietf-sipping-ipv6-torture-tests discuss some of the potential
issues.

> I feel like if we simply try to match the two from each 
> other, we will not be able to maintain the original design 
> beauties behind each address structure.  Correct me if I am wrong.

I'm not sure that I understand the matching comment.  The current
understanding is that an IPv6 address does not equal an IPv4 address
from a SIP equality perspective.  However there are obviously
situations/services on a device where they might be treated the same:
identity, access control, etcetera.

There are situations where an IPv6 address contains an IPv4 address.
However I currently doubt that we need to discuss the matter beyond
highlighting such an address concerning equality and maybe additionally
503, looping, downgrading to IPv4, etcetera.

---

From: "Jane Jiang" <[email-masked]>
Date: Thu, 6 Dec 2007 18:39:16 -0800

Hi Brett,

Though IPv6 was initially designed to address the IP address space
issue, I feel like the mobility feature afforded by IPv6 address design
is a true value added.  

When we are mapping from IPv6 to IPv4, we will certainly loose some
information.  However, when we are mapping from IPv4 to IPv6, how can we
expand the digits in a way that we can actually  make the mapped IPv6
address to support mobility?  That is my question.

Thanks!

Jane

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: Thursday, December 06, 2007 10:26 AM
To: Jane Jiang; [email-masked]
Subject: RE: [Sip] comments on draft-gurbani-sip-ipv6-abnf-fix-00

> I am wondering if you will want to discuss about the impacts of 
> mapping between IPv6 address and IPv4 address?

> not be able to maintain the original design beauties behind each 
> address structure.  Correct me if I am wrong.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 7 Dec 2007 16:07:31 -0500

> Though IPv6 was initially designed to address the IP address 
> space issue, I feel like the mobility feature afforded by 
> IPv6 address design is a true value added.  
> 
> When we are mapping from IPv6 to IPv4, we will certainly 
> loose some information.  However, when we are mapping from 
> IPv4 to IPv6, how can we expand the digits in a way that we 
> can actually  make the mapped IPv6 address to support 
> mobility?

The IPv6 mobility topic would likely be beyond intended purpose of the
draft.

Your question would potentially be relevant to
draft-ietf-sipping-v6-transition.  

If IPv6 mobility has impacts upon SIP which have not been analyzed
within SIPPING or another working group, the community would likely
welcome the analysis even if it doesn't produce new SIP related
requirements.

Thanks,
Brett