At 1:12 PM +0200 10/30/04, Brian E Carpenter wrote:
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.
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.
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.
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------