Subject: Re: RFC 2732 and Zone IDs

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Oct 2004 13:12:50 +0200

We discussed this with respect to the scoped address document a
while back (message attached below).

Here's my view (clipped from some off-line dialogue) about why we
didn't go into panic mode to get this fixed in the URI syntax
(2396bis, already approved as full Standard, which obsoletes 2732)
at that time:

> Because it has no *reasonable* use? Is it reasonable to use HTTP this way?
> It doesn't really bother me that it isn't covered by the latest URI syntax
> (and therefore not by IRI syntax). I must say I have largely ignored
> the whole scoped address debate, so I missed this when we did the original
> work on RFC 2732.

In any case this is a dead duck, unless the IESG wants to recall 2396bis
from the RFC Editor, which seems absolutely unjustified to me.

    Brian

-------- Original Message --------
Subject: Re: I-D ACTION:draft-ietf-ipv6-scoping-arch-02.txt
Date: Wed, 01 Sep 2004 10:11:59 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: IPv6 <[email-masked]>
References: <[email-masked]> <[email-masked]>	<[email-masked]>
<[email-masked]>

Your suggested changes seem fine to me. I certainly don't
think we should recall the draft from the RFC Editor. If the
changes can be made as editorial updates, that's fine. If not,
they can simply be kept for the next version.

I'm really sorry I didn't spot this during the Last Call.

    Brian

JINMEI Tatuya wrote:
>>>>>>On Tue, 31 Aug 2004 10:05:33 +0200,
>>>>>>Brian E Carpenter <[email-masked]> said:
>
>
>>P.S. I'm quite aware that this has already passed the IESG,
>>but it will obviously have to be updated one day, so please
>>keep these comments in a safe place.
>
>
> I interpret this to mean that you are not requiring to revise the
> draft addressing your comments.  But it seems we can reflect some of
> your points during the editorial work with the RFC editor.
>
> If my understanding is NOT correct, please say so explicitly.
>
> Now going to the comments:
>
>
>>>>However, the typed URL is often sent on the wire, and it would cause
>>>>confusion if an application did not strip the <zone_id> portion
>>>>before sending.  Note that the applications should not need to care
>>>>about which kind of addresses they're using, much less parse or strip
>>>>out the <zone_id> portion of the address.  Also, the format for
>>>>non-global addresses might conflict with the URI syntax [13], since
>>>>the syntax defines the delimiter character (`%') as the escape
>>>>character.
>>>
>>>[13] is RFC 2396, which will be obsoleted by draft-fielding-uri-rfc2396bis
>>>
>>>Actually there is no problem with the conflict, except that in a URI,
>>>a percent sign has to be percent-encoded as %25. So zone_id 1 would
>>>be represented in a URI as %251.
>
>
> Yes, but the point is that the escaped format would not be able to be
> passed to, e.g., getaddrinfo() directly.  It would decrease the
> benefit of the extended format with the "%" delimiter.  Also, we
> then could not simply copy-n-paste a literal IPv6 address with a zone
> identifier from output of some other command.  It would also decrease
> the benefit of the format.
>
> So, for example, does it help to revise this paragraph as follows?
> (i.e., adding several sentences at the end of the paragraph)
>
>    However, the typed URL is often sent on the wire, and it would cause
>    confusion if an application did not strip the <zone_id> portion
>    before sending.  Note that the applications should not need to care
>    about which kind of addresses they're using, much less parse or strip
>    out the <zone_id> portion of the address.  Also, the format for
>    non-global addresses might conflict with the URI syntax [13], since
>    the syntax defines the delimiter character (`%') as the escape
>    character.  This conflict would require, for example, that the
>    <zone_id> part for zone 1 with the delimiter be represented as
>    '%251'.  But it also means that we could not simply copy a
>    non-escaped format from other sources as input to the URI parser.
>    Additionally, if the URI parser does not convert the escaped format
>    before passing it to a name-to-address library, the conversion will
>    fail.  All these issues would decrease the benefit of the textual
>    representation described in this section.
>
>
>>>>Hence, this document does not specify how the format for non-global
>>>>addresses should be combined with the preferred format for literal
>>>>IPv6 addresses.
>
>
>>>I'd want a URI syntax expert to check, but I'm not sure that
>>>there is any problem with %251, %252, etc. It's ugly, but using
>>>literal addresses is always ugly. The real question is whether there
>>>would ever be any *need* to specify a zone_id in a URI.
>
>
> Regarding %251 or %252, see above.
>
> Regarding the "real question", I'd say it should at least be rare, so
> we could simply remove the URI issues if it can be a blocking problem.
> But I can imagine some usage similar to the example shown in Section
> 11.4, considering many today's leaf routers have web interface, and
> thus I believe providing some notes might help.
>
>
>>>>As for the conflict issue with the URI format, it
>>>>would be better to wait until the relationship between the preferred
>>>>format and the URI syntax is clarified.
>>>
>>>It is clarified by draft-fielding-uri-rfc2396bis.
>>>
>>>
>>>>...In fact, the preferred
>>>>format for IPv6 literal addresses itself has the same kind of
>>>>conflict.
>>>
>>>No, it's a very different conflict. % is a global escape character
>>>in URIs, which is why it has to be escaped itself as %25. The colons
>>>in IPv6 addresses are simply delimiters. I think this sentence is
>>>unnecessary.
>
>
> I would say those were the same problem before the clarification of
> rfc2396bis.  But I understand that the conflict with colons is not an
> issue any more with rfc2396bis.
>
> So, perhaps we can just simply this paragraph to:
>
>    Hence, this document does not specify how the format for non-global
>    addresses should be combined with the preferred format for literal
>    IPv6 addresses.  In any case, it is recommended to use an FQDN
>    instead of a literal IPv6 address in a URL, whenever an FQDN is
>    available.
>
> Does this make sense to you?
>
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					[email-masked]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 30 Oct 2004 11:54:26 -0400

>>  the whole scoped address debate, so I missed this when we did the original

Brian originally made this statement in an exchange with some URI/IRI 
authors/experts and the IESG regarding my "discuss" position on 
draft-duerst-iri-10.txt.  My response was:

"I don't know.  A year ago, I would have said "no", but with 
documents on the IESG agenda like draft-black-snmp-uri-08.txt, I am 
taking a new view of URIs.  This document defines a URI syntax that 
can be used for access to SNMP objects, and one of the use cases 
includes having a local SNMP manager that is accessed through a URI 
-- the URI then being translated into an SNMP request that is sent to 
the agent via SNMP.

So, URIs can, effectively, be used as a programmatic interface to 
other applications running on the local system.  In that sort of 
case, I think we very well might need to include scoped addresses in 
URIs.  And, IMO, it would be better to have a standard way to do this 
than to live in a world where folks just insert an unencoded % and 
some parsers pass it through cleanly, others escape it for you and 
still others return an error -- which is how the current behaviour of 
URI parsers has been described in this thread."

BTW, I don't think it was a mistake to omit this when RFC 2732 was 
published, as the IPv6 Scoped Address Architecture (which defines 
zone IDs) was only recently approved by the IESG for publication at 
PS.

>from the RFC Editor, which seems absolutely unjustified to me.

The discussion with the URI/IRI authors doesn't seem to be moving in 
the direction of recalling 2396bis.  It seems preferable to write a 
new document that defines an IPv6 address encoding that includes a 
zone ID.  This could be done under the IPvFuture mechanism described 
in 2396bis.

I'm certainly willing to let the URI/IRI folks figure out the best 
way to fix this problem, but I don't understand how the fact that 
2396bis is in the RFC editor queue makes this problem a "dead duck". 
In fact, I'm not sure I understand what "this" is referring to in the 
sentence above.

I don't know exactly where this will end up, but given the fact that 
2396bis will obsolete RFC 2732 when it is published (which I didn't 
realize when I started this thread), I agree that an update to RFC 
2732 doesn't make sense.

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 Oct 2004 13:24:53 +0100

Just to explain my "dead duck" comment, indeed I meant it only
in the context of the documents currently in the publication
queue. If a real requirement appears then it is pretty obvious
what to do - extend the URI syntax appropriately and modify
every URI parser.

     Brian

Margaret Wasserman wrote:
> "I don't know.  A year ago, I would have said "no", but with documents 
> on the IESG agenda like draft-black-snmp-uri-08.txt, I am taking a new 
> view of URIs.  This document defines a URI syntax that can be used for 
> access to SNMP objects, and one of the use cases includes having a local 
> SNMP manager that is accessed through a URI -- the URI then being 
> translated into an SNMP request that is sent to the agent via SNMP.
> 
> So, URIs can, effectively, be used as a programmatic interface to other 
> applications running on the local system.  In that sort of case, I think 
> we very well might need to include scoped addresses in URIs.  And, IMO, 
> it would be better to have a standard way to do this than to live in a 
> world where folks just insert an unencoded % and some parsers pass it 
> through cleanly, others escape it for you and still others return an 
> error -- which is how the current behaviour of URI parsers has been 
> described in this thread."
> 
> published, as the IPv6 Scoped Address Architecture (which defines zone 
> IDs) was only recently approved by the IESG for publication at PS.
> 
> The discussion with the URI/IRI authors doesn't seem to be moving in the 
> direction of recalling 2396bis.  It seems preferable to write a new 
> document that defines an IPv6 address encoding that includes a zone ID.  
> This could be done under the IPvFuture mechanism described in 2396bis.
> 
> I'm certainly willing to let the URI/IRI folks figure out the best way 
> to fix this problem, but I don't understand how the fact that 2396bis is 
> in the RFC editor queue makes this problem a "dead duck". In fact, I'm 
> not sure I understand what "this" is referring to in the sentence above.
> 
> realize when I started this thread), I agree that an update to RFC 2732 
> doesn't make sense.
> 
> Margaret
> 
> 
> 
>