Hello John,
Sorry I'm behind with my replies.
Post by John C KlensinIf we are having a meeting, I'd like to have time to discuss the
(1) draft-ietf-iri-3987bis and the associated documents.
(2) Approaches such as that represented by draft-klensin-iri-sri
I'll comment on this separately, following up to Dave's crucial comment.
Post by John C Klensin(3) An update to 3987 that preserves the "not a protocol
identifier" and "every valid URI is a valid IRI" principles. As
far as I know, no one is arguing for this, but it is still a
possibility.
"Preserving the 'not a protocol identifier'" isn't a possibility, for
the simple reason that IRIs are defined as protocol elements already.
The first line of the abstract of RFC 3987 says that, it's difficult to
miss!
It would really help if you could actually read the documents you are
trying to criticize, or at least their abstract, or at the very least
the first line of the abstract, so I don't have to repeat this again. I
already told you so in a mail just a few days ago.
Post by John C Klensin(4) Giving up, deprecating/obsoleting 3987, and moving on.
There are other specs that use RFC 3987, so deprecating it doesn't look
like much of an option.
Post by John C KlensinI note that draft-ietf-iri-comparison seems intimately tied to
(1). The intent behind (2) includes standardizing information
sufficiently that a simple XML structured comparison (i.e.,
ignoring irrelevant white space) should suffice without
identifier- or scheme-specific comparison rules.
draft-ietf-iri-bidi-guidelines would probably still be helpful,
but some of the issues it addresses appear to me to disappear.
It is not clear to me whether that discussion can more
efficiently be held in Vancouver, by email, or by some other
method. I'll leave that question in your hands.
I hope we can make a lot of progress on what should happen to SRIs
before Vancouver.
Regards, Martin.