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 PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
