Re: UFN take 2

[Paul-Andre Pays <[e-mail]>]

> 
> 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

approved, that was exactly my proposal, not to impose use of
delimiters, but to standardize the choice when used.

>   - 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.

Approved to, I was just giving an example and I have no special
feeling for ">".  Let's go for square brackets

> 
>      
> 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.
> 

that was exactly my proposal too, just have OSI-DS 23 refer to another
"living document" for additional keywords. AND obviously produce 
and regurlaly update this second document, but independantly

> 
> 
> 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).
> 

Let's see, but I am really strong on this point and ready to argue a
lot! 
  In normal written english are you allowed to "forget" a "," just
  because it happens to be the last char of a line?
  Do you accept that UFN could be spread into texts and processed
  as plain text or do you wish to create in each text processor
  a specific mode for handling UFN?
  aso.... aso.....

> 
> 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.   
> 
> 

I personaly go for a) or b).
We have to be clear on what is an output; it is certainly not what is
generaly displayed on your screen when you are using a high
quality user interface (able for example to adapt to your context,
even your native language). I thus believe that output
will mostly be used as a form of exchange between people.
In such a case I really advocate a single "keyworded form".

This does not meen at all I want to exclude the untyped form of DN you
are promoting (even if I don't share exactly your view). This is just
to say that if typed attributes are used (either by choice or by any
kind of obligation) then I would like to have a single common form
used (without many variants).

> 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.  
> 

Even If I don't share this statement, I do believe that with no harm
the OSI DS 23 could be made to suit both concerns. Then users 
and practice will decide, but my bet is that both forms are needed
and will exist for long. What experience will show will be the exact
place and usage of each representation (typed or not)

Regards,

-- PAP