Subject: Re: MIBs for IPDC and SGCP

From: Ari Ollikainen <[email-masked]>
Date: Tue, 10 Nov 1998 12:11:11 -0800

>On Nov 9,  1:45pm, Jagdish wrote:
>> Subject: MIBs for IPDC and SGCP
>>
>> Is IETF involved in the work related to the "Definitions of Managed
>objects" for IPDC protocols and SGCP?
>> If yes, when can I expect them to be available as RFCs?
>
>This is an action that will undertaken by the -- yet to be chartered --
>"media gateway control" working group. If you feel a strong need for this,
>your contributions are indeed welcome.
>

        Hmmm... I guess this is another case of vendors' premature
        announcement of IETF /interest/activity/support of their
        protocols...Here's an excerpt from Level 3's press release from
        8/5/98:

        TAC Submits IPDC Protocol to Standards Bodies

        The TAC has submitted the IPDC specification draft to both the
        Internet Engineering Task Force (IETF) and to the International
        Telecommunications Union (ITU) standards bodies. According to Elliott,
        ``bridging of IP-based networks with the PSTN will be facilitated by
        the efforts of the TAC as well as by initiatives already underway in a
        number of forums. Our IPDC draft will be up for discussion at the IETF
        and ITU meetings in August and September, respectively. We look
        forward to discussing the breadth and scope of the IPDC specification
        within both of these organizations.''

      OLTECO                    Ari Ollikainen
      P.O. BOX 3688             Networking Technology and Architecture
      Stanford, CA              [email-masked]
      94309-3688                415.517.3519

---

From: "Rick H. Wesson" <[email-masked]>
Date: Tue, 10 Nov 1998 14:10:20 -0800 (PST)

this one from central caught my eye.... with all the ICANN
registry things happening i thought this might be of interest too.

> CENTRAAL ANNOUNCES IETF STANDARDS EFFORT AND REALNAMES SUBMISSION
>
> FALL INTERNET WORLD/NEW YORK, NY (October 7, 1998) Centraal Corporation,

<snip>

> Centraal recently sparked new activity within the IETF directed toward
> creating standards for Human Friendly Identifiers. Centraal has
> submitted
> a document which describes the semantics of RealNames as Human Friendly
> Identifiers by defining the relationship of the RealName system to
> existing Internet identifiers: URLs (Uniform Resource Locators) and URNs
> (Uniform Resource Names). A subsequent document was submitted by Michael
> Mealling of Network Solutions, which proposes requirements for Human
> Friendly Identifiers. Centraal embraces Network Solutions participation
> in this process and is committed to delivering a common standard as soon
> as possible..

the draft is available at
http://www.ietf.org/internet-drafts/draft-popp-realname-hfn-00.txt

i love this the part from the draft....

> 2. The RealName system as a Human Friendly Name scheme
>
>  A "RealName" is a name registered with Centraal Corporation.
>  Centraal Corporation owns and manages the RealName repository
>  database and is the sole assigning authority for RealNames.

everybody wants to be NSI =)

-rick

---

From: "Rick H. Wesson" <[email-masked]>
Date: Tue, 10 Nov 1998 14:10:20 -0800 (PST)

<snip>

-rick

---

From: "Perry E. Metzger" <[email-masked]>
Date: Tue, 10 Nov 1998 18:38:51 -0500

> > CENTRAAL ANNOUNCES IETF STANDARDS EFFORT AND REALNAMES SUBMISSION

Everyone likes to pretend they have a standards effort going.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: Tue, 10 Nov 1998 18:38:51 -0500

Perry

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 10 Nov 1998 18:39:07 PST

Re:

> > creating standards for Human Friendly Identifiers.

There will likely be a BOF at IETF (we've gotten a tentative
approval);  Michael Mealling is setting up a mailing list
and a web page. The general idea was discussed at length in the
URI working group, and described in RFC 2276 ("Architectural Principles
of Uniform Resource Name Resolution")

   In contrast to URNs, one can imagine a variety human-friendly naming
   (HFN) schemes supporting different suites of applications and user
   communities.  These will need to provide mappings to URNs in tighter
   or looser couplings, depending on the namespace.  It is these HFNs
   that will be mnemonic, content-full, and perhaps mutable, to track
   changes in use and semantics.  They may provide nicknaming and other
   aliasing, relative or short names, context sensitive names,
   descriptive names, etc.  Their definition is not part of this effort,
   but will clearly play an important role in the long run.

RFC 2345 ("Domain Names and Company Name Retrieval"),
and the more recent submissions:

   draft-popp-realname-hfn-00.txt
   draft-mealling-human-friendly-identifier-req-00.txt
   draft-mealling-human-friendly-identifier-arch-00.txt

Certainly there will be multiple registrars of 'friendly names',
but there's a place for organizations that act as an
authority by dint of checking trademark ownership, relevance and
appropriateness of the names assigned. D&B, Thompson Register,
AOL go-words, Netscape Internet Keywords, Netword... all of these
exist as name registrars. Given the large amount of activity
in this area, starting work on standards seems appropriate.

(will announce mailing list / web page etc. as soon as it is
set up.)

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 10 Nov 1998 18:39:07 PST

Larry

---

From: "Rick H. Wesson" <[email-masked]>
Date: Tue, 10 Nov 1998 22:56:26 -0800 (PST)

Larry,

thanks for the heads up.

On Tue, 10 Nov 1998, Larry Masinter wrote:

[snip]

i am *very* much against any IETF protoocls that creat registries
of any kind that create new registry problems. i'm not saying that
HFN are not a GoodThing(tm), but that greed is bad.

I would hope that HFN's don't require a central registry, simular
to the Internic's.

---

From: "Rick H. Wesson" <[email-masked]>
Date: Tue, 10 Nov 1998 22:56:26 -0800 (PST)

Larry,

thanks for the heads up.

[snip]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 1998 13:45:13 +0000

We here all know that submitting an Internet Draft, or running
a BOF, or getting an Info RFC published, mean very little in
formal IETF terms.

Joe Average who reads PR material doesn't know that.

Incidentally if you are interested in the user friendly names
issue, have a look at RFC 2345. This is hardly a new topic.

  Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Nov 1998 13:45:13 +0000

Brian Carpenter

---

From: Michael Mealling <[email-masked]>
Date: Wed, 11 Nov 1998 10:57:31 -0500 (EST)

> Everyone likes to pretend they have a standards effort going.

Well, we are attempting to follow the process. We hope to have
a BOF scheduled in Orlando. The topic has been one that the
URN/URI groups have been discussing off and on in an informal way
since '92. A few of us have some proposals and the market 
seems to be ready for it.

Come to the BOF. We'd love the input!

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Wed, 11 Nov 1998 10:57:31 -0500 (EST)

-MM

---

From: Michael Mealling <[email-masked]>
Date: Wed, 11 Nov 1998 11:08:40 -0500 (EST)

> HFN are not a GoodThing(tm), but that greed is bad.

I'm not going to touch that one with any pole of any length! ;-)
/* for the smiley impaired the above statement is meant in good */
/* humor and nothing more */

> I would hope that HFN's don't require a central registry, simular

There is good general concensus that the HFN space is a flat
namespace. The only proposals that exist for how to not have
it be a central registry really do nothing more than fancy load
balancing. If someone has a way of federating a flat, uniform 
namespace without requiring the addition of federating 
identifiers to the name, I'd really like to see it since would
have some interesting applications in other areas.

---

From: Michael Mealling <[email-masked]>
Date: Wed, 11 Nov 1998 11:08:40 -0500 (EST)

---

From: Michael Mealling <[email-masked]>
Date: Wed, 11 Nov 1998 11:17:59 -0500 (EST)

> a BOF, or getting an Info RFC published, mean very little in

Very true. Those of us who've been here for a while know that.
That's why I'm trying to do more than just that. That's why
we're holding the BOF and attempting to get enough support
for a Working Group. My personal intent is for a Standards
Track document. We'll see how the BOF goes though...

> Joe Average who reads PR material doesn't know that.

But those who implement the applications do (or at least
we hope they do)...

> issue, have a look at RFC 2345. This is hardly a new topic.

Yep. And RFC 1737. The URI group identified friendly names 
as an important part of any future architecture way back in '92.
We just got slightly sidetracked by the URN problem.

What has changed between then and now is the entire timing
of the indusry: the users want it; there are companies that
want to provide the service; and the expertise within the
IETF has gotten to the point where we are pretty sure it
can be done in an open and scalable way.

---

From: Michael Mealling <[email-masked]>
Date: Wed, 11 Nov 1998 11:17:59 -0500 (EST)

---

From: "Rick H. Wesson" <[email-masked]>
Date: Wed, 11 Nov 1998 11:06:20 -0800 (PST)

michael,

i have no problem with HFN, but i do see that they require the
management of a "flat name space." i do have conserns with
companies backing HFNs so that new regestries can be developed
as profit centers.

we have had *huge* probmems with simular management issues with
3 other "flat name spaces" namely (.com, .net, and .org) my only
wish is to avoid simular management problems. 

i hope that your BOF, and wg will address such issues.

-rick

---

From: "Rick H. Wesson" <[email-masked]>
Date: Wed, 11 Nov 1998 11:06:20 -0800 (PST)

michael,

-rick

---

From: Michael Mealling <[email-masked]>
Date: Wed, 11 Nov 1998 17:00:23 -0500 (EST)

> i hope that your BOF, and wg will address such issues.

That is a very good question. BOFs, Working Groups and the
IETF in general are notoriously bad places to discuss
policy issues before the technology is even nailed down
yet. I really have no clue about how to approach questions
like this at this point in the HFN discussion. I also
think that HFNs are to useful to allow discussions of those
issues to completely sidetrack the work.

If anyone has any suggestions for how to approach that
issue I'd really like to hear them. I'm not sure how to
debate the subject though since I don't think the discussion
is appropriate to the mailing list at this point in the
game.

-MM

---

From: Michael Mealling <[email-masked]>
Date: Wed, 11 Nov 1998 17:00:23 -0500 (EST)

-MM

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Nov 1998 18:19:51 -0500

> can be done in an open and scalable way.

Companies may want it, but...

A number of companies who are providing such services seem
to want to have a monopoly on that service - in other words,
people have to go to their monopoly in order to register
their name in the service.  I cannot imagine that IETF will 
endorse any such scheme.

If there are going to be standard HFNs, there cannot be a monopoly 
on resistration or resolution services, the HFNs themselves have 
to be independent of the resolution service used (which almost
certainly means that not all services will be able to resolve 
all HFNs, and you'll get different results from one resolution
service to another), and a user has to be able to choose which 
resolution service(s) to use when looking up HFNs.

It should also be apparent that HFNs cannot be globally unique - that
is a single HFN might have multiple meanings, because almost nobody has
the exclusive right to use any particular word or phrase in all
countries, independent of context.  ("famous" trademarks are the 
exception rather than the rule)   This means that any request to resolve 
an HFN may result in multiple answers and/or require the user to 
specify additional information to constrain the query.  This, coupled
with the requirement that URNs be long-term persistent, implies that 
HFNs (or any other "human friendly" name) cannot be URNs.

All of which means that certain companies who want IETF to promote
their version of HFNs, may lack clues about both HFNs and IETF.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 11 Nov 1998 18:19:51 -0500

Keith

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 12 Nov 1998 10:41:09 +0100

>have some interesting applications in other areas.

If you give up on uniqueness, federation is relatively easy.
Former discussions I've seen assume that in non-unique spaces,
the resolution service and the name source are connected; this
might not be true, just like the equality registry=registrar turned
out to be unnecessary in the guaranteed-unique namespaces.

Algorithms for name registration go something like this:

Unique namespace:			Non-unique namespace

1) Ask for name			1) Register name
2) Discover conflict			2) Discover conflict
3) Fight				3) Fight
4) Register				4) Resolve ownership

In the period between 1) and 4), resolution of a name in the unique
namespace gives no answer; in the non-unique namespace, it gives two.

I don't think HFNs can be unique.

                  Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 12 Nov 1998 10:41:09 +0100

Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 1998 10:21:37 +0000

Exactly.

The difference in "uniqueness" between Acme and Acme.com escapes me.

(with apologies to all the companies in the world called "Acme")

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 1998 10:21:37 +0000

Exactly.

  Brian

---

From: Christian Huitema <[email-masked]>
Date: Thu, 12 Nov 1998 08:31:01 -0500 (EST)

On Nov 12, 10:21am, Brian E Carpenter wrote:
> Subject: Re: What HFNs are not (was Re: Draft IDs in PR...)
> Exactly.
> 
Brian,

The difference is that there can only be, by construction, exactly
one "acme.com", while there are, in fact, multiple companies calling
themselves "acme", or "acme something."

The HFN equivalent of "acme.com" is when an access to "www.acme.com"
returns a page pointing to the various companies with a claim to
the name "acme", instead of arbitrarily picking one of them. Indeed,
we would want to have something a little more formalized that an HTML
full of anchors and pointers, and that is the whole purpose of
the whole topic.

The classic way to allow several claims on the same name is to 
have a data base pairing each claim with a unique identifier, such as
a fully qualified domain name or, possibly, some unique binary 
"handle."  Implementation of such data bases is trivial if you
centralize, somewhat more difficult if you don't. One could claim
that the web search engines are examples of centralized implementations.

Distribution implies that there are multiple databases, or
"registries."  There have been many attempts in the past 10 years to
develop a technology that would help you find all the registries that
know something about ACME -- variations of X.500, whois, solo, and
probably many more.  I am not convinced that any of these technologies
scales -- X.500 relies on hierarchies, which negates HFN, and the
centroid alternatives relies on the natural structure of the dictionary,
which may or may not be adequate.  I believe that this is still a 
research issue, but we can all hope that the BOF will unearth some
cool new technology. (Would be great if the techno was not protected
by too many harsh patents, but I would not day dream that...)

Possible IETF actions would include the navigation and access protocols
(variations of Whois such as rwhois or whois++ come to mind), and also
the linkage between names and applications -- how do we go from
a name to an email address, a web page, a voip address, etc. In fact,
it would be useful to develop access protocol and linkage technology
even if the market evolves towards multiple centralized databases.

-- 
Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Thu, 12 Nov 1998 08:31:01 -0500 (EST)

Brian,

-- 
Christian Huitema

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Nov 1998 22:58:04 +0800

>is appropriate to the mailing list at this point in the

I suggest that before you have a BOF you should formulate a draft working
group charter.  

The purpose for this is to carefully state the problem and equally
carefully state the approach that will be taken to solve the problem.  One
form of problem statement is to indicate what benefits will accrue from the
solution that you are proposing to produce.

This realm of naming is notoriously succeptable to high administrative and
operational complexity, poor scaling and poor utility.  It would be useful
to have some idea ahead of time, as to why this working group's output
won't suffer these problems.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                       Tel: +60 (19) 3299 445
<mailto:[email-masked]>             Post Office Box 296, U.P.M.
                                         Serdang, Selangor 43400 MALAYSIA
Brandenburg Consulting                                          
<http://www.brandenburg.com>                       Tel: +1 (408) 246 8253
Fax: +1(408)273 6464              675 Spruce Dr., Sunnyvale, CA 94086 USA

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Nov 1998 22:58:04 +0800

d/

---

From: Michael Mealling <[email-masked]>
Date: Thu, 12 Nov 1998 10:34:37 -0500 (EST)

> I suggest that before you have a BOF you should formulate a draft working

That's the next thing on our agenda. Join [email-masked] 
([email-masked] to subscribe) if you want to join in the
fun for scoping the BOF and group to something that can be accomplished.

-MM

---

From: Michael Mealling <[email-masked]>
Date: Thu, 12 Nov 1998 10:34:37 -0500 (EST)

-MM

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 1998 17:56:05 +0000

Christian

I think you missed my point (but everything you say is true).

My point is this: any claim that an alternative to DNS can somehow
create uniqueness is spurious. 

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Nov 1998 17:56:05 +0000

Christian

  Brian

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Nov 1998 09:12:28 +1000

>  create uniqueness is spurious. 
 
I think we should be collating these kind of pithy statements. Keith Moore
seemed to be saying as well something like:

  You can have uniqueness, or you can have searching, but you can't have
  both in hierarchical naming models without compromising one or other goal.

  [my paraphrase]

-George
--
George Michaelson         |  DSTC Pty Ltd
Email: [email-masked]    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Nov 1998 09:12:28 +1000

[my paraphrase]

-George

---

From: "Ted Wolf Jr" <[email-masked]>
Date: Thu, 12 Nov 1998 19:22:46 -0500

Comment:

I think that we need to accept the fact that many human friendly identifiers
already exist and are in fact in common wide spread use today. We should
take a closer look at the need for matching what the end user commonly uses
with the human unfriendly key identifiers that are the basis for the
existing databases that already exist as directories and have already built
the validation systems required.
The concept of re-defining a set of human friendly identifiers or forcing
wide spread registration of "common names" is fraught with the potential for
failure. Especially if you would expect the users to pay for the privilege
of registering a name they already are entitled to, or previously have paid
for

Ted Wolf Jr.
Sr. Information Strategist
iAtlas

-----Original Message-----
From:	Michael Mealling [mailto:[email-masked]]
Sent:	Wednesday, November 11, 1998 11:09 AM
To:	Rick H. Wesson
Cc:	[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject:	Re: Draft IDs in PR... (was Re: MIBs for IPDC and SGCP)

--
----------------------------------------------------------------------------
----
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:
14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: "Ted Wolf Jr" <[email-masked]>
Date: Thu, 12 Nov 1998 19:22:46 -0500

Comment:

Ted Wolf Jr.

-----Original Message-----
From:	Michael Mealling [mailto:[email-masked]]
Sent:	Wednesday, November 11, 1998 11:09 AM
To:	Rick H. Wesson
Cc:	[email-masked]; [email-masked]; [email-masked];
[email-masked]

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 13 Nov 1998 01:03:15 -0500

The HFN problem is the same as the TLD problem and the same as the
spmadexing problem on the web and, I'm sure, the same as other
problems of which I am unaware.  Human level naming is fraught with
dangers.  I do not believe there is very much of a technical component
or solution, only political/legal, financial, and/or social
considerations.

If you get a list of the "ACMEs", the problem just reduces to who is
listed first, how that is determined, how to stop an organization from
creating millions of pseudo-separate ACMEs that all indirectly point
to it so as to swamp out all the other ACMEs, etc. etc.  If you try to
solve this by having unique identifiers (i.e., DNS) or
filtering/judging the ACMEs, then you probably need ways to have
multiple parties providing this service (i.e., multiple roots).  But
network effects are likely to make one dominant (i.e., the IANA/IETF
recommended root which has always been used by at least 99.5%+ of the
Internet) with the result that no matter who runs it or what their
policies are, there will be any number of people who claim it is a
crime against humanity that the policies don't follow their agenda,
let them make the profits they want, etc., and the operators of the
dominant service(s) must be forced to change the mutually imcompatible
ways these people want.

I just don't see how you are going to do any better than approximately
letting the various web search/portal operators each do their own HFN
thing with their own policies, so people can choose.  If you truly
search aross or combine independent databases of info on HFNs, you'll
just have oranizations creating millions of such databases that
feature themselves most prominently so as to swamp out their
competitiors.

I would be surprised if engineering can provide anything more than
minor second order assistance here.  I don't mind their being a BoF.
But if real engineering ideas that are of real help don't emerge, a
working group should not be formed.  It will just sink into this
morass.

Thanks,
Donald

From:  Christian Huitema <[email-masked]>
Date:  Thu, 12 Nov 1998 08:31:01 -0500 (EST)
Message-Id:  <[email-masked]>
In-Reply-To:  Brian E Carpenter <[email-masked]>
	             "Re: What HFNs are not (was Re: Draft IDs in PR...)" (Nov 12, 10
:21am)
References:  <[email-masked]> 
	    	<[email-masked]>
To:  Brian E Carpenter <[email-masked]>, Keith Moore <[email-masked]>
Cc:  [email-masked], [email-masked]
Content-Type:  text/plain; charset=us-ascii

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 13 Nov 1998 01:03:15 -0500

Thanks,
Donald

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 13 Nov 1998 00:42:05 PST

> or solution, only political/legal, financial, and/or social

It's hard to ask you to judge before the proposed charter has
been published, but the most important goals are to deal with
the engineering issues around interfaces to 'friendly names',
not the issues of registration and uniqueness. In particular,
whether or not 'friendly names' are unique, what people will
type in order to try to 'look them up' will probably not be
an exact match. 'friendly names' will not be restricted to
ASCII letters and numbers.

To do a case analysis, either it IS possible to create
a registry of unique names, or it is not. But even in if it is,
what users will type will likely not be an exact match; a
user will type 'Delta' even if the 'unique name' wanted is
'Delta Airlines' or 'Delta Consulting Company of Chicago'.

If we want unique names, we can't insist that they also
be short names, except in rare circumstances where the
short name is globally recognized.

But let's not deep end on the uniqueness issue or even
registration mechanisms, and focus on:

a) what's the interface to the matching / resolution process?
b) what is the mapping to URLs and URNs? Can we use some
  of the existing or proposed mechanisms?
c) how does it link into the browser?
d) what does a publisher of a database of 'friendly names'
   need to offer to resolution services.

These *are* engineering questions for which IETF can come
up with solutions. The social/political/legal ramifications
aside, adding more top level domains in DNS won't help those
people who want to publish Kanji or Hebrew or Arabic
'internet names', even those who would like their names
to have spaces in them.

> to it so as to swamp out all the other ACMEs, etc. etc.

I agree, these problems require administration, judgement, and
responsibility. In the end, the quality of a name space is judged
by how strenuously the process by which the namespace is allocated
is protected from pollution.

> If you try to

Virtual landfill impinging on virtual beachfront.

> feature themselves most prominently so as to swamp out their

This is a useful analysis, and points at some pitfalls to be avoided.

> working group should not be formed.  It will just sink into this

I'm hoping we can skirt the morass for long enough to deal with
the other actual engineering issues. If nothing else, if we can
move the TLD debate toward a system that actually solves some
of the OTHER problems with using DNS for our name space, we'll
have done the Internet-using world a service.

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 13 Nov 1998 00:42:05 PST

---

From: Keith Moore <[email-masked]>
Date: Sun, 15 Nov 1998 23:16:49 -0500

> problems of which I am unaware.

I disagree, but probably because you and I have different things
in mind when we say HFN.

In my mind, HFNs are not much more than a convention for encoding
human-friendly search strings (probably in a URI-compatible 
syntax), a protocol to be used to send one of those strings to a 
search service, and a well-defined format for the response.  

It's not the same as the TLD problem for several reasons:

- we won't have the notion of "owning" a part of HFN space
  (though we might need to have a way of specifying search constraints 
   and some of those might need to have a controlled vocabulary )

- an HFN lookup can produce multiple answers
  (you'll get lots of hits if you search for "ACME")

- different HFN lookup services are allowed (expected!) to produce
  different answers to the same query  - there's no requirement
  for consistency

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 15 Nov 1998 23:16:49 -0500

Keith

---

From: "Martin J. Duerst" <[email-masked]>
Date: Mon, 16 Nov 1998 15:57:08 +0900

> I disagree, but probably because you and I have different things

It might be worth to think about other names than HFN for what's
being worked on. "HFN" seems to attract a lot of attention, but
also produce quite a bit of confusion.> 

> syntax),

That would then be something like "search:ACME" or so?

> a protocol to be used to send one of those strings to a 
> search service,

Well, we wouldn't need a new protocol, just a few conventions
on top of HTTP, maybe ?

> and a well-defined format for the response.  

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

---

From: "Martin J. Duerst" <[email-masked]>
Date: Mon, 16 Nov 1998 15:57:08 +0900

Regards,   Martin.

---

From: Michael Mealling <[email-masked]>
Date: Mon, 16 Nov 1998 08:48:40 -0500 (EST)

> That would then be something like "search:ACME" or so?

I would suggest something shorter since the longer it is the
less friendly it becomes...

> Well, we wouldn't need a new protocol, just a few conventions

At some stage. There is a requirement for sub-second responses so
I doubt if relying totally on HTTP would be appropriate. See
draft-mealling-human-friendly-identifier-arch-00.txt
for some examples of my thoughts...

-MM

---

From: Michael Mealling <[email-masked]>
Date: Mon, 16 Nov 1998 08:48:40 -0500 (EST)

-MM

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Nov 1998 10:09:52 -0500

> also produce quite a bit of confusion

As far as I can tell, any TLA with the letter "N" seems to produce 
quite a bit of confusion.  My biggest concern about chartering an
HFN group is this: no matter how the WG charter constrains the 
HFN problem, there will be people who will insist that HFNs 
solve problems that HFNs weren't intended to solve.  this will
tend to either (a) restrict the solution space to the null set,
or (b) make HFNs useless (or remove the "human friendly" property).

my second biggest concern is that most of the work in HFNs 
(as I see them) is defining the constraint spaces, which is 
not something that IETF is competent to do.  IETF is 
competent to define what HFNs look like and the protocols
used to do HFN lookups, and the rest must be left to other groups.

> That would then be something like "search:ACME" or so?

something like that, but maybe with optional constraints like

hfn:ACME?type=business/retail,product=anvil,location=us/nm/los%20alamos

(Obviously the constraints aren't human friendly.  I don't imagine
that the user would type them in; rather, I imagine that they would
be supplied by having the search service ask the user questions about
what kinds of things the user was looking for.)

> Well, we wouldn't need a new protocol, just a few conventions

maybe.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Nov 1998 10:09:52 -0500

maybe.

Keith