Subject: [Ietf-not43] comments on IRIS

From: [email-masked] (Andrew Newton)
Date: Fri, 04 Oct 2002 10:54:13 -0400

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zark-11530-1033744112-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Over the past month or so, I've been keeping a file on comments about 
IRIS that I have either received via email or from the notes we have 
created as we have gone through the process of implementing both a 
client and a server.

I believe it to be constructive and good feedback for -01 drafts.  Your 
opinions are appreciated.

-andy

--=_zark-11530-1033744112-0001-2
Content-Type: text/plain; name=future-changes-to-iris-drafts; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="future-changes-to-iris-drafts"

In draft-ietf-crisp-iris-beep:

  1) Make reference to RFC2732 when placing IPv6 addresses in IRIS URI's.
  2) Make data streams application/xml+beep (see #4 in iris-core).
  3) From email comment:
       In your draft, you might want to consider explicitly stating what other
       profiles need to be supported on the same BEEP implementation. For example,
       it would probably be worthwhile to discuss whether SASL is ever likely to be
       necessary, whether TLS should be supported, if so which cypher suites
       minimally need to be supported, and so on.
     from another email comment on this issue:
       probably referring to the usual security considerations thing
       that you'll find in rfc 3288, 3195, etc.
  4) Make serverName (or whatever it is) mandatory.
  5) Alter beep profile stuff to support serviceInquiry (see #1 on iris-core).
  6) Changes according to #3 in iris-core.
  7) Need to address the comparison of expected authority to the DN in an X.509 cert
       delivered over TLS.  Proposal is that the DN would be SRV protocol component +
       authority.  So an "authority" for verisignlabs.com would be "cn=iris,cn=tcp,dc=verisignlabs,dc=com".
       Will need to look into the x.500 attribute names for host addresses.  Perhaps they
       would be "cn=iris,cn=tcp,ipServicePort=3434,ipHostNumber=10.0.0.1"  The latter
       should be discouraged.
       A better idea is to simply store the authority in the subjectAlternativeName.
       Something like a URI like iris://<authority>/iris1/QUERY/ID ( see #2 and #3 in iris-core).
  8) Place wording in security considerations about following referrals and using SASL/PLAIN.
     This generally is a bad idea as you may be handing your password to an unknown server.
     This is a general problem with referral systems.  It is better to use digital certificates
     or a non-replay-able password scheme such as CRAM-MD5 or OTP (though OTP would mean that
     you have missed a coordination step with real servers).

In draft-ietf-crisp-iris-dreg:

  1) Remove findHostsByDomain query as it is redundant with the entity lookup for domains.
  2) Add findDomainsByHost query as that is what findHostsByDomain should have been.
  3) Make ipv4Addres and ipv6Address in entity class consistent with the element names in 
     the host element.
  4) Add a Registrar object containing registrar contact info plus an "authority" for creating searches. 
     This makes it clearer what is to be returned and also allows explicitly stating who registrars
     are in serialized XML.
  5) Change name of <holder> to <registrant>.  This is much more in conformance with the CRISP
     requirements docs.
  6) Might want to add a Registry object as well. See #4.
  7) Place <domainContact> in a <domainContacts> container element because that makes it easier
     on some DOM API's.
  8) Change "e-mail" in contact to "eMail" to be more uniform.
  9) Place host contacts in a <hostContacts> container.
 10) Place IP addresses in containers.
 11) Change <lastModifiedDateTime> in host object to <lastModificationDateTime> to be more consistent
     with the contact and domain object.
 12) Change name of <findDomain*> query elements to <findDomains*>.
 13) Change ref to fictious iris:translatedContact to dreg:translatedContact.
 14) Change findDomainByHolder to findDomainByRegistrant to match requirements terminology.
 15) Make beginsWith optional for find* queries.  Possibly add error codes for
     specifying that beginsWith or endsWith or baseDomain must be given.
 16) Specify that entity names are case insensitive (see #10 in iris-core).
 17) Might want to specify that beginswith and endswith are case insensitive.
 18) Change <holder> so that it encloses an <entityURI> object.
 19) Change domain and other objects to only use entityURI and to quit embedding.
     This makes normalization easier.
 20) Make the downward domain delegation referral explicit in domain.
 21) Add an alternate email address to the contact.
 22) Make registry objects optional in the domain object.
 23) Add a language attribute to contacts to better support localization.

In draft-ietf-crisp-iris-core:

  1) Move serviceInquiry to transport level.
  2) Specify mandatory named query in entity class QUERY of ID or something and putting ID
     in the iris1 namespace. ID should include "authority" as mandatory and contact info as
     optional.
  3) With the above, it is possible to allow an exception to IRIS URI as always being an entity URI.
     If query component is absent, it means the "iris1/QUERY/ID".  See above.
  4) Mandate XML be UTF-8 only and then defer content type and encoding to transport layers.
  5) Change host reference to talk about "authority" instead of host and port. This is
       consistent with the use of SRV records.
  6) Add optional "commonName" attribute to iris:entityURI element. Allows clients to
     get hints as to what they are pointing to so users can pick and choose what to resolve
     next.
  7) Add a thisEntityURI attribute to <searchContinuation> thus allowing them to be
     serialized as named queries.
  8) Change to irisSerialization to be an unbounded choice of result and searchContinuation.
     This allows searchContinuations to be written out and reloaded. See #7.
  9) Specify that registry types must specify whether their entity names are
     case sensitive or case insensitive.
 10) Specify that entity classes are always case insensitive. (probably need to think
     about this some more as it relates directly to the XML Schemas.  perhaps a better
     idea is always case sensitive but always lower case and hyphenated instead of
     camelBacked thus allowing for schema conformance and ease of use in URI's).
 11) Specify that the QUERY entity class is in the iris1 registry.
 12) Make thisEnityURI mandatory on all result objects. Specify that it is appropriate
     to return referred to objects in the result set. The match up is then done with
     the entityURI.
 13) Change result section to have multiple sections of answer,additional, error.
     Answer will be either iris:result types or searchcontinuation or entityURI 0..*.
     Additional is iris:result types 0..*.  Error would be one of the current errors.

--=_zark-11530-1033744112-0001-2--