Carl-Uno
>To: IETF-Announce:;
>Cc: RFC Editor <rfc-editor@isi.edu>
>Cc: Internet Architecture Board <iab@isi.edu>
>From: The IESG <iesg-secretary@ietf.org>
>Subject: Protocol Action: Uniform Resource Identifiers (URI): Generic
> Syntax and Semantics to Draft Standard
>Date: Thu, 6 Aug 1998 12:56:34 PDT
>Sender: scoya@ns.cnri.reston.va.us
>
>
>
>The IESG has approved the Internet-Draft 'Uniform Resource Identifiers
>(URI): Generic Syntax and Semantics' <draft-fielding-uri-syntax-04.txt>
>as a Draft Standard. This has been reviewed in the IETF but is not the
>product of an IETF Working Group.
>
>This document updates RFC1808 and RFC1738.
>
>The IESG contact persons are Patrik Faltstrom and Keith Moore.
>
>
>Technical Summary
>
>This document revises and replaces the generic definitions in RFC 1738 and
>RFC 1808. Revision was needed because of last years experience in
>implementations of various URL schemes, aswell as the creation of the URN
>specification. Clearifications were needed regarding many basic assumptions
>in the old documents which was not spelled out explicitely. All significant
>changes from the prior RFCs are noted in Appendix G.
>
>Working Group Summary
>
>Discussion has been very intense regarding if the document should be about
>URL schemes, or URI schemes. Even when consensus was found on this issue,
>it was obvious that various reviewers had different opinions on basic
>definitions. Alternative papers were produced, but the discussion converged
>to an updated version of this document.
>
>Definitions of functions and methods that can only be applicable to some
>URI schemes were also up for debate. Some parties wanted those
>(specifically fragments and relative URIs) in separate documents extracted
>from this general syntax document, while others claimed a need for
>describing not only syntax but also algorithms and methods for for example
>calculating the resulting URI from a relative URI existing inside a
>document.
>
>The conclusion was at the end that the description of the methods for some
>basic algorithms (like relative URIs) should stay in the document because
>it can be used in several URI schemes, and in those cases relative URIs
>should be the same.
>
>
>Protocol Quality
>
>Patrik Faltstrom reviewed the specification for IESG.
>
>It has been tested on:
>
> Mozilla/4.03 [en] (X11; U; SunOS 5.5 sun4u; Nav)
> Lynx/2.7.1 libwww-FM/2.14
> MSIE 3.01; Windows 95
> NCSA_Mosaic/2.6 (X11;SunOS 4.1.2 sun4m) libwww/2.12
>
>
>
>RFC Editor:
>
>Please insert the following text as an IESG Note:
>
>This paper describes some kind of "superset" of all functions and methods
that
>can be applied to URIs. It consists of both a grammar and a description of
basic
>functionality for URIs. To understand what is a valid URI, both the grammar
>and the apropriate description have to be studied. Also, some functions and
>methods described only works in some URI schemes, and some only with
>certain content types (i.e. regardless of scheme used).
>
>
>
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com