Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/97apr/urlreg-minutes-97apr.txt

Text File | 1997-05-29 | 10KB | 234 lines

Editor's Note:  These minutes have not been edited.


The following are the minutes of the URLREG (URL Scheme Registration)
BOF session held in
Memphis, Tennessee.  Rich Petke <[e-mail]> and Ian
King <[e-mail]> are co-chairs of the BOF, and Rich conducted
the session.  Minutes were taken by Lisa Dussealt of Microsoft.

Discussion of scope of the BOF
----------------

We will resist all discussion of the generic URL specification -- it's a
separate topic under consideration by the IESG.  We will avoid covering
specific URL proposals-- we will only cover the process by which these
become standards.

Discussion of open issues in current draft by Larry Masinter
-----------

Major open section of the draft is the URL scheme registration process
    open issue also internationalization
    section 2.1.1 -- conflicts with generic URL spec??

Issue: how 2.3.1 does not contradict the directive that new URL schemes
be proposed only if things cannot be done another way

Discuss open URL schemas and how they would move forward (zigmond-media,
hoffman-ailto, callaghan...)

Charter
Q: Should this WG's charter include the task of moving existing schemes
toward the standards track?
A. (harald): No.  This group should only define the procedure by which
new schemes move forward.
Q. Is there a separate group that will exist to look at these schemas
and approve them?
A. There is a URN registration group fumbling with the same registration
process issues.
It is unclear what is the difference between URL and URN.
As long as we don't have a procedure we can't move proposed schemas to
standards.
Q. Should there be a different procedure from the existing IETF
procedure of moving from proposed to draft to standard?
A. (harald) What you can do is different, so the procedure is different.
It is not clear that every URL scheme should be standards track -- doing
that was just a stopgap procedure.

Decision made to revisit the charter at the end of the meeting

Discussion on current URL process I-D
-------------------------------------

1.  Registration process

Proposal: submit an I-D, move to proposed, then to draft standard.
Create a process that is not too easy and not too cumbersome to
encourage the right quantity and quality of standard URL schemes.
Q. Can we define a strategy to differentiate private URL schemes from
standard schemes, i.e. "x-protocol" for private and "protocol" for
standard?
A. (larry) It's too hard to move from private name to the real name when
it becomes widely used.
Q. What is the consequence of unregistered URL schemes? are they bad?
A. (harald) This topic should be abandoned.  First decide what the
registration procedure should be then explore the ramifications.
Q. Have there been any known URL collisions? Has there been a problem?
Perhaps there should be two tracks, one official, one unoffical -- but
maybe there isn't a collision problem.
A. Only collisions have been with extensions of names, such as
extensions of the mailto syntax with extra information.  There has been
leakage of internal-only names such as AOL: with people expecting those
schemes to work more widely than they do.
issue: The end-user doesn't know our rules so we have to be careful to
avoid failures.
First track should be first-come, first-serve -- people can reserve a
name so that there is no collision, without needing to define a syntax.
Second track (standard) should define the syntax so that it can be
widely used.
It matters a lot whether the process takes a month or a year -- if the
standards track process is short, then we don't need a fast track.

Issue: what if there is a name on the unofficial track which we want to
use on the official track?

Q. Have there been in recent times in some other area an example of a
swift standards track?
A. (harald) no.

Rich:  I'm hearing that registration is an important component to avoid
collisions. Also good syntax definition is required for wide use.
Finally, I'm hearing that IETF standard track is too slow.  We would
like to keep all sanctioned URL schemes within the IETF.

Issue: I think the standards track is quite fine -- even putting dozens
of new schemes through the existing standards track is fine.

Idea: we can allow private URL schemes to do whatever they like
response: No, we do need to define even private URL schemes to avoid
user confusion.

Larry: I dont' think it's good for private schemes to go standards track
because it will clutter up the process for no good reason.

Q. Is there a procedure in the IANA for abandonment of registered items?
A. The IANA will operate any registry it is asked to operate according
to the rules they are given. We can write the rules for IANA to add and
delete items to their registry.

Proposal: first step register with IANA
second step publish scheme/syntax as informational if it is private or
put through standards track if it is to be widely used

Counter-proposal: IANA scheme that everybody can participate in, can
register a name provided they have defined a syntax/scheme and a
contact.  This process might have a form to complete and if teh form is
in order IANA accepts the entry and the name is registered.

Q. Is it too much work for the IETF to accept and look at <>20
informational rfc's?
A. (harald) No.  What I'm more concerned about is conflicts like having
Compuserve register a "aol://" scheme or Microsoft register a "java://"
scheme.
We're getting into the fine points of mechanics in order to get around
the problem of over-registration.  How do we decide who gets "java://" ?
can we avoid that?

Note that the doc proposes a 2-person review panel appointed by the area
directors, which would have advisory capacity only.

Issue: review panel should have the community that implemented the
related functionality also review the proposal.  Any URL which covers a
protocol should be reviewed by that protocol community.

Issue: Names in URLs should not be trademarks.

Rich: We will take this onto the list.

2.  Internationalization Issues

Larry:  We need consensus on internationalization, using character
encoding schemes.  Transcription might not be as robust as the existing
ascii method.  We don't want to encourage use of something that doesn't
work just to gain internationalization.  I'd like to hear from others
than the few voices heard on the list.  Currently in the syntax draft,
characters come from a limited repertoire.

Consensus: we should not cover the character issue in this group - we
need to define the process first.  What's in the doc now is all right.

Will those implementing URL schemes use this encoding?  (larry)  I have
yet to hear that anybody will do anything with this!!  We need
implementation.

A.  There is a major Japanese browser that uses Kanji characters but I
don't know how they are doing this.  It was a conversion from something
else.
A. We are starting to use unicode

Issue: there's a lot more than just web browsers...

More investigation into implementation is required.  This may be a
chicken-and-egg problem, to resolve we need to try implementing.

Decision:  We will take this to the w3c mailing list to reach more
browser implementors.

3. Conflict between I-D's -- section 2.1.1

Many people are putting :// into there URL schemes from the impression
that every URL needs "://".  We need to clarify the intent of the
double-slash.  Does it introduce a host name?  Tim Berners-Lee says it's
an indication of the top-level of a scheme and not necessarily an
internet host name, and as such it can be used widely.

Decision: this will be fixed in the next draft.

4. Conflict between making proxies work and why have a URL if it can be
done with something else (section 2.3.1)

Harald acknowledged having started this line of inquiry.  LDAP has
mappings into HTML/HTTP which lose interesting information, but other
schemes don't lose this.  The document should say whether it's one kind
or the other...
This was intended logically to say that URLs should have demonstrated
utility.  You can demonstrate utility by having a gateway to get at the
information to show what the URL would get you.
Decision: This should be worded more clearly, more strongly.  take out
the reference to HTTP/HTML because you can gateway into anything to
demonstrate usefulness.

New issue: We don't want to consider the difference between URLs and
URNs in this draft.
A:  Right.  The URN group was still deciding whether all URNs start with
URN. Now we have consensus that it starts with URN so no issue.
Decision: omit section 2.6.1

New issue: More verbiage around 2.2.5 -- URLs that are not related to
data sources (i.e. mailto).  We need to be more explicit about what they
should do

Back to Charter
---------------

Decision: Strike the reference to proxies and HTTP/HTML from the charter
Decision: Keep the goal of addressing security consideration in the
charter

Milestones:
We hope we can have a new I-D by June 1.  This requires resolution from
the WG or inclusion of alternatives for open issues in the I-D.

Should we strike the mention of I18N in the schedule?  Isn't this
somebody else's problem?
Alter the June 1 milestone to state that it will contain discussion of
all known open issues, one of which just happens to be
internationalization.  This milestone should be more general.

Change final milestone to "submit I-D to IESG as BCP"
Decision: should have two documents
    - Checklist (informational)
    - Process (BCP)
Decision to change the charter as described; Rich will submit an amended
charter to the list and, after discussion, to the Area Director.

Ian King, QA Lead <[e-mail]>
Microsoft Information Retrieval                                    24
hours in a day, 24 beers in a case.
Internet Services Business Unit
Coincidence?