Subject: [Ietf-not43] [Fwd: I-D ACTION:draft-ietf-rescap-rc-01.txt]

From: [email-masked] (Eric A. Hall)
Date: Wed, 06 Mar 2002 21:41:26 -0600

This is a multi-part message in MIME format.
--------------83FCB864C96A32FF96477A46
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This should be considered as another potential candidate for the not43
work, although it needs a little bit of work to make it usable (redirects
in particular), and it would need a champion. Still, it meets most of our
requirements, and is therefore a potential alternative to the other two
proposals already on the table.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
--------------83FCB864C96A32FF96477A46
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-rescap-rc-01.txt
Date: Wed, 06 Mar 2002 13:42:09 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Resource Capabilities Discovery Working Group of the IETF.

	Title		: The Resource Catalog
	Author(s)	: K. Moore
	Filename	: draft-ietf-rescap-rc-01.txt
	Pages		: 34
	Date		: 05-Mar-02
	
This memo describes version 3 of the Resource Catalog.  The Resource
Catalog (RC) is a service for storing and obtaining metadata that
describes network-accessible resources.  This service is primarily
intended for use by clients prior to accessing, or attempting to access,
a particular resource.  The RC service may thus be used (for example) to
inform a client as to which of a variety of features are supported by
the resource, or which methods may be used to access the resource, or
which of a small set of locations may be used to access the resource.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rescap-rc-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rescap-rc-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-rescap-rc-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-rescap-rc-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rescap-rc-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

--------------83FCB864C96A32FF96477A46--

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 06 Mar 2002 22:26:58 -0600

Michael Mealling wrote:

> Are there other issues you think RESCAP would need?

I only read through it once, and quickly at that. A detailed comparison to
the requirements document would take a fair bit of time, and the
requirements document itself needs a bit more work.

One thing that the LDAP angle offers over RC is that OIDs allow attribute
names to be internationalized easily, while RC relies on ASCII strings
which is less straightforward (and internationalization needs to be added
to the requirements doc, btw).

I also mentioned redirects because of:

 | 8. Differences from RC version 2

 |    RCv2 supported the notion of redirects - the ability to redirect
 |    queries for portions of URI-space - at the protocol level; this is
 |    omitted in RCv3 because they were too much trouble to use.
 |    Redirects could be implemented in RCv3 by making them ordinary
 |    attributes and by using the QUERY_RECURSE bit in queries for that
 |    attribute name.

That and some of the items listed in the open issues section seem to
suggest that this would need some more time in the oven before it could
really compete with the other options. It doesn't even have a port number
yet. But for the most part, it seems like it would work as well as any of
the other approaches, in rough scope anyway.

I can look at it in greater detail later this week.

---

From: Michael Mealling <[email-masked]> (Michael Mealling)
Date: Wed, 6 Mar 2002 23:15:41 -0500

> proposals already on the table.

The intent of the RC is that redirects are defined data types for
a particular purpose. I.e. not43 would define what a redirect meant
in its terms and then define that attribute type for use with the RESCAP
protocol...

Are there other issues you think RESCAP would need? I'm not suggesting
that not43 use RESCAP but being the RESCAP chair I'm looking for
critiques of the protocol documents....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

---

From: [email-masked] (Keith Moore)
Date: Thu, 07 Mar 2002 22:33:43 -0500

[not on the list yet, replying via the archive...]

> requirements document itself needs a bit more work.

I'll try to look at the requirements document myself to see how close
I think it is.  

> to the requirements doc, btw).

OIDs are easy to use as RC attribute names (or values); just represent them 
as ASCII strings of the form

1*DIGIT * ("." 1*DIGIT)

you can even do wildcard queries for OID subtrees.  

>  |    attributes and by using the QUERY_RECURSE bit in queries for that

RCv2 supported redirects at the protocol level, meaning that you 
could tell the server "for any URI lexicographically between x and y,
return a redirect to server z rather than trying to do the lookup".  
This introduced a number of oddities that had to be sorted out -
for instance, how to handle redirects with subset and overlapping 
ranges - and it tended to slow down the server.  Basically it was 
an attempt to generalize something like DNS's NS handling.  But
it really wasn't general enough for URI redirection, and we found 
that it was easier to manage a separate redirect for each URI than to 
manage a separate list of redirect ranges.  Also, RCv2 predated NAPTR
records.  Once we had NAPTR records defined they seemed to provide 
a roughly-equivalent capability to the "redirects based on lexicographic 
ranges" that RCv2 provided.

Again, I'll have to look carefully at the !43 requirements document
before I understand whether RC's existing mechanisms would be 
satisfactory.  But thanks for considering it.

Keith

---

From: [email-masked] (Eric Brunner-Williams in Portland Maine)
Date: Fri, 08 Mar 2002 15:20:08 -0500

>> to the requirements doc, btw).

I wish I knew what "internationalized" means. Is it:

        o substitute one universal ACR/CCS/CEF/CES with another?
                a la ASCII -> UNICODE
        o substitute any (or some) ACR/CCS/CEF/CES(s) with others?
		a la message relay from one domain to another

> ...

What is necessary to obtain "lexicographic ranges" if the answer to the
above is the first answer, and the range is in the ideographic subset of
that universal ACR/CCS/CEF/CES?

Cheers,
Eric

---

From: [email-masked] (Eric A. Hall)
Date: Fri, 08 Mar 2002 12:49:19 -0600

Eric Brunner-Williams in Portland Maine wrote:

> >> names to be internationalized easily, while RC relies on ASCII
> >> strings which is less straightforward (and internationalization
> >> needs to be added to the requirements doc, btw).
> 

I probably should have said localization. What I am thinking about in
particular is that the not43 "client" uses locale data to present
attribute names to the user in the appropriate language for that user.
Rather than having the server generate "Name:" the client generates "Nom:"
or whatever is appropriate for the local user, and using OIDs for the
identifiers makes this localization simpler for the clients.

The data has to support internationalized values, but that stuff probably
shouldn't be translated on-the-fly. It may be prudent to specify that
things like postal addresses, etc, should be stored in the system in
English so that international mail delivery works, however.

---

From: [email-masked] (Eric Brunner-Williams in Portland Maine)
Date: Sat, 09 Mar 2002 13:17:45 -0500

> an English keyword (from a controlled vocabulary) as an OID.

Now there's the gem of an idea for something useful that falls
under the rubric of Foobar Considerations, pulling out the damned
	"strings used in this protocol"
so they can be treated as controlled vocabulary and statically or
dynamically localized ("name" -> "nom" (en -> fr), without reference
to encodings, local or soi disant "universal".

I personally don't view string substitutions as exhausting the
scope of "i18n", but milage varies. The relevancy of this note is
not limited to the !43 activity, and it may have no relevance to
that activity.

Eric

---

From: [email-masked] (Keith Moore)
Date: Fri, 08 Mar 2002 23:36:39 -0500

> identifiers makes this localization simpler for the clients.

or more precisely, it makes it equally complex for all clients.

But there are mail user agents that substitute non-English words
for the commonly-displayed message header fields.  The fact 
that English words are used for the header field names doesn't seem
to impede them from doing this.  It's as about easily to translate
an English keyword (from a controlled vocabulary) as an OID.