Re: UFN take 2

[Steve Hardcastle-Kille <[e-mail]>]

Paul-Andre (+Alan)

Thanks for these very usful comments.

1) Brackets.   Let me make a proposal.
  - the basic  syntax will remain undelimted, so that it can be used 
  	that way if desired
  - a delimited form should be added, for those that need this
  - the delimiters should be square brackets.   Thus:
     [Paul-Andre-Pays, Inria, FR] or if you prefer
     [CN=Paul-Andre Pays, O=Inria, C=FR]
     I think that <> is already overloaded.  Square brackets could easily 
     be integrated with RFC 822 and X.400 UIPs modelled on 822, 
     which is also attractive.

     
2) Adding more attributes.

I do not want this to extend to a general text descripton of all attributes.
This is a much much larger task. I can see an argument for doing it, but it
should be undertaken separately.   More importantly, we should not 
delay this document until it is done.  Lets discuss the second document as a
new work item.

The syntax has an escape mechanism, so there is no need to registre
pathological cases.  However, I am very anxious to include any other
attributes used for naming.  I HOPE that complex syntax handling can be
avoided.  I included all of the attribute types I know of which are being
used for naming.  Please let me know of any I have missed.  (I regard DNS
representation + X.400 O/R Address representation as too experimental at
present).  


3) "," as a separator.  I note your view to make the change noted in the
issue.  I'd like to hear other views (particularly anyone who is strongly
going to support the current position - I do not wnat to make this change,
and then hear violent complaints).


4) Single vs Multiple keys.  I can see a number of places where this might
end up.  

 a) single keywords (which would be short)

 b) multiple keywords, with a recomended output format (I suspect that
 short keys is the only form that could be agreed on, and so this would 
 be effectively the same as a))

 c) multiple keywords, with manadatory support of all forms on input,
 and no requirement on output.   This allows long keywords to be used,
 probably with a multiline display, in contexts where the semantics of the
 keyword need to be made very clear.   I do take your point about language,
 which is a good one.   


My view:  I HATE typed names.  So do most users.  I would like to remove
typed naming from X.500 (and nearly suceeded, but that is another story). I
want to focus on the typeless form, and only use types when I have to.  I
guess that I still see OSI-DS 24 (UFN) as the real solution.  



Steve