[Ietf-not43] comments on IRIS
Andrew Newton
anewton@ecotroph.net
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--