Subject: Re: I-D ACTION:draft-ietf-ipv6-scoping-arch-02.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 01 Sep 2004 13:07:08 +0900

I've not seen a response to my previous message, but I'd like to make
a quick decision on the next step.  To make the point clearer, I'm
going to summarize my plan below.  Explicit acknowledgements (either
positive or negative) would be very helpful, but I'll basically start
the proposed procedure pretty soon even if I cannot get a response.

The plan is to update the last two paragraphs of Section 11.7 and
reorganize those to three paragraphs as attached below, in the
editorial work with the RFC editor (so there will be no new revision
of this document as an Internet-Draft).

Revised paragraphs:

   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'.  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.  In any case, it is recommended to use an FQDN
   instead of a literal IPv6 address in a URL, whenever an FQDN is
   available.

(end of the paragraphs)

					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
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Sep 2004 10:11:59 +0200

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:
> 
> 
>>>>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)
> 
>    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.
>>>>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:
> 
> Does this make sense to you?
> 
> 					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 02 Sep 2004 18:07:49 +0900

>>>>> On Wed, 01 Sep 2004 10:11:59 +0200, 

> they can simply be kept for the next version.

Okay, thanks.

					JINMEI, Tatuya