Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-requirements-02.txt

From: [email-masked] (Eric A. Hall)
Date: Mon, 13 Jan 2003 17:13:24 -0600

Presumably the original post was lost to many people as part of the
post-xmas purging.

on 12/25/2002 6:50 PM Eric A. Hall wrote:
> A couple of additional comments on the requirements draft
> 
> 1) slight rewording of 3.1.3
> 
>  | 3.1.3 Standard and Extensible Schemas
>  |
>  |  The service MUST define standard schemas for the exchange of data
>  |  needed to implement the functionality in this document.  In addition,
>  |  there MUST be a means to allow the use of schemas not defined by the
>  |  needs of this document.  Both types of schemas MUST use the same
>  |  schema language.  The schemas MUST be able to express data elements
>  |  with identifying tags for the purpose of localization of
>  |  internationalized data element labels
> 
> The last sentence seems to imply that i18n data is to be expressly
> identified when the only real concern is that the service be able to
> accomodate this data, whether tagged or not. Localization tagging is
> another issue, and that kind of tagging should be provided when the
> untagged form would cause corruption.
> 
> I would therefore suggest that the sentence be rewritten as "The schemas
> MUST be able to accomodate internationalized data elements, and MUST be
> able to denote any localized forms of any data which would otherwise cause
> interoperability problems."
> 
> 2) Does section 3.2.3 define a requirement for an organizational lookup,
> similar to but different (larger) than the contact lookup as defined in
> section 3.2.1? For example, does it mean that rather than finding all of
> the domains I may have registered over the years, I need to be able to
> find all of the domains that were registered under the name of my company
> or one of my clients?
> 
> This would involve defining something that could be used as an org-handle
> and then finding something to map this onto, which isn't as simple as just
> mapping an email address (and even that isn't easy).
> 
> I think this is a good idea and an interesting feature which would give
> clear benefit over legacy WHOIS. I just want to make sure I'm reading it
> as what I think it is?
> 
> Can we change this to a SHOULD? I note for effect that section 3.2.5 only
> calls for a MAY requirement, and that is existing functionality.
> 
> 3) I'd like to see a requirement for versioning. In those cases where the
> nature of the protocol, schema or data elements need to be adjusted, there
> will be a need for end-stations to negotiate or identify the version(s) in
> use. I guarantee this will happen. For example, in the case of LDAP-WHOIS,
> it may be that the core schema has to be extended, or that a specific
> schema associated with a specific resource has to be redefined.
> 
> I feel sufficiently strongly about this that I think it should be a MUST
> requirement. EG, "Service proposals MUST provide mechanisms for
> identifying and/or negotiating the version of the protocol, schema, or
> data elements which constitute the service to an extent that any or all of
> these may be changed and the service will continue to function."
> 

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