Re: New revision of the procedures draft

At 13:15 98/07/20 -0400, Rich Petke wrote:
> Here is a revised draft of the registration procedures for new URL scheme
names.

Great!


> I'm submitting this to the I-D editor this afternoon as well.
> 
> Please take a few moments to review this and post your comments to this
> list.  There is still time for me to get another revision out before the
Chicago
> meeting.
> 
> Some points that need work:
> 
> 1) I borrowed a lot of the text from the MIME type registration RFC.  One
> carry-over was the reference to the mailing list "ietf-types".  We will most
> likely want a separate mailing list for URL scheme names than MIME types.
> Suggestions?

- Definitely a separate list.
- Use an address that contains @ietf.org or @iana.org or so, not
  any kind of company. If the above are unfeasible, we can easily
  provide something @w3.org.



There is one comment that I made earlier that seems to have got lost.
I'll just make it here again:


> 2.6.  IANA Procedures for Registering URL scheme names
> 
>    The IANA will only register URL scheme names in the IETF tree in
>    response to a communication from the IESG stating that a given
>    registration has been approved. Vendor and personal types will be
>    registered by the IANA automatically and without any formal review
>    as long as the following minimal conditions are met:
> 
>    Scheme Name Syntax:  The syntax of the requested scheme name
>    (including the assigned producer designation in the case of vendor
>    tree registrations), MUST conform to the syntax for such as
>    specified in RFC [URI-SYNTAX].  While encouraged, the syntax for the
>    actual scheme does not have to conform to the general syntax
>    specified in RFC [URI-SYNTAX].
> 
>    Security Considerations:  The application for registration of a
>    scheme name MUST include a discussion of the security
>    considerations inherent in the scheme.


Please add here something like:

Character Encoding Considerations: The application for registration of
a scheme name MUST include a discussion of the character encoding
considerations used for the scheme. [e.g. whether the character encoding
is based on UTF-8 as suggested in RFC [URL-GUIDELINES] [2]].


It is important that this appears in the registration. It's a big help
to see e.g. for the IMAP protocol that it's URIs are based on UTF-8, or
for the FTP protocol that its URIs should be based on UTF-8, although
some of them are not, and even in the case of HTTP, it helps to know
that chaos reigns.

This also brings this document in line with the Guidelines document,
where character encoding issues are explicitly mentionned.


> 2.8.  Registration Template
> 
>      To: [email protected]
>      Subject: Registration of URL Scheme Name <name>
> 
>      URL Scheme Name:
> 
>      Security considerations:

Please add here something like:

Character encoding considerations:


> 3.0 Security Considerations
> 
>    Information that creates or updates a registration needs to be
>    authenticated.
> 
>    Information concerning possible security vulnerabilities of a
>    protocol may change over time.  Consequently, claims as to the
>    security properties of a registered URL scheme may change as well.
>    As new vulnerabilities are discovered, information about such
>    vulnerabilities may need to be attached to existing registrations,
>    so that users are not misled as to the true security properties of a
>    registered URL scheme.
> 
>    Delegations of a name space should only be assigned to someone with
>    adequate security.

A section on multilingual considerations would also be nice. If you
want, I can provide one.



Regards,   Martin.