Subject: [Ietf-not43] off-list comments on requirements

From: [email-masked] (Eric Brunner-Williams in Portland Maine)
Date: Thu, 14 Mar 2002 15:48:18 -0500

Andy,

I'm trying to "stay out" of the !43 design space, so ignore anything
that is predicated upon profound ignorance.

> 1) The internationalization considerations section should
> state that names of attributes or tags (or whatever you wish
> to call them, and this will probably vary depending on the
> final set of technologies used) should be displayed according
> to a users locale and the values must be able to support
> internationalized content.  (why start with an easy one :) )

This is posing i18n as a presentation probem. You may. I prefer to ask
"what does this mean if the encoding is EBCDIC?" to help me through to
the perfection of blindness. Characters can be distracting. If you are
going down the UNICODE path, don't indicate it by design indirection.
Locale has a specific meaning (see XPG 3 where we defined it, for better
or worse, in a world pre-UNICODE).

> 2) The text restricting the scope of domain registries in
> section 2.1.4 is too vague.  Language is needed to stipulate
> the association of a domain registry with a gTLD or ccTLD.

Your call, not mine, but why wouldn't the implementor(s) of the server
and clients using same at the delegation "whois-not43.wabenaki.net" be
interested in using "TLD tech" for an SLD? Ask Scott about this one, I
recall we (provreg) got an IESG hit on overspecification on just this
point.

> 7) As a general note, the draft does not specify what should
> be in contact data or operation data... or in other words, help
> specify what will eventually be the contents of the schemas.
> I don't know if the requirements draft is the right place for
> this information.

If not-43 provides no necessary operational service to network operators
(and similar), then perhaps no technical contact is needed. FYI, in the
:43 list I've suggested that no registrant contact is needed, as :43 is
for the necessary operational service to network operators (and similar).

We discussed the "thick vs thin" (where's authoritative state) registry
model when on this point in provreg (social vs technical data), see the
attempt by Ross Raeder at the problem in the provreg definitions doc.

Eric

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 14 Mar 2002 19:46:56 -0600

> going down the UNICODE path, don't indicate it by design indirection.

There shouldn't be a requirement for any specific encoding or repertoir,
and none is given, although there should be a nod to the existing IAB
guidelines on the matter. That's pretty much what the drafts requirement
currently does. My request is to define the expected functionality, rather
than the implementation methodology.

I suppose the logical extended verbiage for this would include "specify
how the proposal provides for the necessary i18n and l10n functionality"

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Leslie Daigle)
Date: Fri, 15 Mar 2002 09:38:08 -0500

Howdy,

> recall we (provreg) got an IESG hit on overspecification on just this

I think the intent was that the scope should be restricted to the needs
of registries providing global registrations services, such as gTLDs
and ccTLDs (today).

So, note the extra indirection -- "scoped to the needs of" not "only
operated by" gTLD and ccTLD registries.

Leslie.

-- 

------------------------------------------------------------
Leslie Daigle
[email-masked]

VeriSign Applied Research
------------------------------------------------------------

---

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

Morning Leslie,

What is the technical point of distinction?

Is an inapplicability statement in plan to explain why jrandom-sld.tld can
not use whois-not43?

Assuming an Act of God (tm) enlightens the New.Net menagerie, and they loose
all other policy and technical encumbrences and take to frequent bathing and
brushing between meals.

For what technical reason(s) will whois-not43 be incapable of providing service
to the stld good-hygiene.new.net in its .good-hygiene tld representation?

No recursive descent is a possibility. Dependency upon explicit delegation is
another. I can't think of any others off hand, and neither seems particularly
valuable properties to select as design points.

$.02, ignore as you whois-not43'ers see fit,
Eric

---

From: [email-masked] (Andrew Newton)
Date: Fri, 15 Mar 2002 10:19:24 -0500

Eric,

Thanks for the comments.

> or worse, in a world pre-UNICODE).

Like I said, why start with an easy one.  Since one of the other
requirements is:

  3.1.2 Minimal Technical Reinvention

so I don't see the !43 process trying to tackle anything new in
i18n space.  If XML or LDAP or MIME or whatever does not support
i18n to the fullest extent possible, then we are just gonna have
to live with it.  The advantage here is that we have 17 years of
experience with newer technologies since RFC954.  But let's not
push it to 27 years.

> recall we (provreg) got an IESG hit on overspecification on just this

It seems finding the words to express this are not going to be easy.
The intent is to narrow the scope so we don't need to consider the
requirements of things like alternate roots or 3rd level registries
in .com or domain registries in that vain.  By associating it back
to a gTLD or ccTLD, it would take into account .biz as well as .co.uk
and so forth.

-andy

-- 
Andrew Newton
VeriSign Applied Research
[email-masked]

---

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

Morning Andy,

> i18n space.

Suppose that instance A of !43 and instance B of !43 differ in some
aspect of mechanism or policy or ... that some property of !43 has
non-universal scope. Do you plan on discovering the scope boundaries
and negociating the reconcilliation of the property?

If so, isn't encoding a candidate for "some property"?

You can of course posit global scope for whatever. rfc954 maked no
assumption, and one could use EBCDIC, just to be unique, beautiful,
and consistent with the intent, and specification, of rfc954.

>          ... If XML or LDAP or MIME or whatever does not support
> i18n to the fullest extent possible

After doing i18n work pre-iso2022, post-iso2022, for XPG/3 locales,
for double-byte encodings, multi-byte encodings, wide- and multi-byte
encodings in three operating systems, I don't know what this means.

I think I know what it means for XML (see 4.3.3 of the 1.0 TR).

Well, keep me informed as I'm idly curious,
Eric

---

From: [email-masked] (Eric A. Hall)
Date: Fri, 15 Mar 2002 14:31:13 -0600

At the risk of proving that I'm not sure what you're going on about, I
will add the following comment:

> Is an inapplicability statement in plan to explain why jrandom-sld.tld
> can not use whois-not43?

> For what technical reason(s) will whois-not43 be incapable of providing
> service to the stld good-hygiene.new.net in its .good-hygiene tld
> representation?

AFAICT, there is no prohibition against that, nor would the wording
provide such a prohibition.

WRT my proposal in particular, something like co.uk. can have its own
servers as long as either (1) .uk issues referrals to that server for
queries about *.co.uk, or (2) a user points his client to the co.uk
servers as a default action, or (3) both.

IMO, restricting the *focus of concern* to the TLDs just means limiting
the scope of any mental bandwidth required to complete the task. It does
not preclude the participation or activies of the SLD community.

---

From: [email-masked] (Leslie Daigle)
Date: Fri, 15 Mar 2002 17:20:39 -0500

Eric,

What Eric Hall said.

Further comments below:

> Is an inapplicability statement in plan to explain why jrandom-sld.tld can

No; there is nothing in the requirements that says jrandom-sld.tld cannot
use CRISP.

But there *.tld covers a lot of ground, and presumably a lot of creative
and imaginative potential uses for networked information storage services.

I believe the intent in the requirements document was to say that we
are going to declare success when we have captured the requirements
of/on what are today representative of global domain registry operators.

Is there a better way to phrase it?

Leslie.

--

---

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

> Is there a better way to phrase it?

jrandom utterences from parties not currently holding a tld chit or flogging
solutions to tld chit holders are depricated. that works.

would a jrandom-sld.tld operator be correct in assuming that -not43 is
unconditionally applicable, absent some explicit dependency upon some
visibly unattainable condition such as (s == t)? probably not, since
the victory party is set for when one has

	"captured the requirements of/on what are today representative
	 of global domain registry operators."

and presumably there exists one or more requirement for nth-ld operations
not exhausted in 1st-ld requirements.

the strong form is an inapplicability statement, a notice to mariners.
the weak form is hidden shoals, unmarked by bouy or light.

thanks for clarifying the scoping, i'll go back to sleep now, in fact,
i'll unsub and leave you to your good work.

eric

---

From: [email-masked] (Eric A. Hall)
Date: Fri, 15 Mar 2002 18:10:24 -0600

> i'll unsub and leave you to your good work.

Speaking for me, I appreciate your raising the questions, as they force us
to think mo-better about the core issues.