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