hta@isolde.er.sintef.no (Harald Tveit Alvestrand) (03/15/91)
Jacob, thanks a LOT for giving us this stuff early enough to comment on it! In article <605950*@MHS>, JPALME@qz.qz.se (Jacob Palme QZ) writes: |> |> Representation of O/R-addresses for human exchange |> -------------------------------------------------- |> |> Further work was done on this. It is now accepted that |> only semicolon (;) or new line in tables, and not slash |> (/) shall be used between attributes in the |> representation. The fields will be given with the |> innermost value (Given name) first, and the outermost |> value (country) last, except that Organizational Units |> are listed in the reverse order from this. |> |> User Interfaces should to some extent be suitable for |> this format, in the order in which attributes are |> handled and in the abbreviated names given to the |> attributes in the user interface. |> Jacob, please tell us it isn't so, and that the O attribute should still be placed closest to the most significant OU, like before! If your quote is the full and complete truth, there will be NO software capable of deciding whether an address is input in "ISO/CCITT order" or the currently used "complete little-endian" format. -- Harald Tveit Alvestrand Harald.Alvestrand@elab-runit.sintef.no (big-endian) C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald +47 7 59 70 94
JPALME@qz.qz.se (Jacob Palme QZ) (03/15/91)
> From: Harald Tveit Alvestrand <harald.alvestrand@elab-runit.sintef.no> > > Jacob, please tell us it isn't so, and that the O attribute should still > be placed closest to the most significant OU, like before! > If your quote is the full and complete truth, there will be NO software > capable of deciding whether an address is input in "ISO/CCITT order" > or the currently used "complete little-endian" format. I am not sure. I did not participate in that subgroup. Probably the only possible way to avoid confusion between the OU-s, if a big-endian format is chosen (as the group did, I believe) is to number them, OU1=, OU2= etc. I would prefer the presently de-facto accepted little-endian format, mainly because it avoids confusion of the OU-s. I suggest that you talk to Knut Smaaland, the Norwegian representative at the meeting, and submit a paper through him with your concerns for the next meeting. Nothing is finite yet! But the earlier your comments arrive, the larger chance that they will influence the final result.
Stef@ics.uci.edu (Einar Stefferud) (06/20/91)
I understand that the CCIT folk are meeting this week in Ottowa, but I weonder if anyone has an electronic copy of the actual text that was adopted in March. If not, then can someone please provide a copy of the real adopted text coming out of the Ottowa meeting? Thanks...\Stef ----- Begin From: Jacob Palme QZ <JPALME@qz.qz.se> Subject: O/R name component ordering (was: Report from X.400 development X400-Originator: MHSnews.distribution@uninett.no Message-ID: <663647*@MHS> Newsgroups: comp.protocols.iso.x400 Date: 15 Mar 91 15:17:27 GMT X400-MTS-Identifier: [/PRMD=uninett/ADMD= /C=no/;910315161550] To: mhsnews@qz.qz.se > From: Harald Tveit Alvestrand <harald.alvestrand@elab-runit.sintef.no> > > Jacob, please tell us it isn't so, and that the O attribute should still > be placed closest to the most significant OU, like before! > If your quote is the full and complete truth, there will be NO software > capable of deciding whether an address is input in "ISO/CCITT order" > or the currently used "complete little-endian" format. I am not sure. I did not participate in that subgroup. Probably the only possible way to avoid confusion between the OU-s, if a big-endian format is chosen (as the group did, I believe) is to number them, OU1=, OU2= etc. I would prefer the presently de-facto accepted little-endian format, mainly because it avoids confusion of the OU-s. I suggest that you talk to Knut Smaaland, the Norwegian representative at the meeting, and submit a paper through him with your concerns for the next meeting. Nothing is finite yet! But the earlier your comments arrive, the larger chance that they will influence the final result. ---- End
nbevan@ess.cs.ucl.ac.uk (Nigel Bevan) (06/21/91)
Unfortunately the Representation of O/R address standard is out for ISO voting, so it wont be discussed in Ottawa, but in The Hague in October. Meantime, if you have a view, discuss it with your national standards body!
Stef@ics.uci.edu (Einar Stefferud) (06/21/91)
Thanks Nigel -- Fortunately (or unfortunately as the case may be) I find that I had the document in my unread files all along. Sorry to bother you all with my untimely question. However, I was surprised (many of you out there will also be surprised) that I was not offended with the draft, so I will not be making any negative comments to my national body folks. I found the logic of it all to be rather good, and it does not mess up the bit about the order of the OU elements. I must say though that it is not what I would have come up with, but it looks OK to me. Best...\Stef
grimm@eiche.darmstadt.gmd.dbp.de (Ruediger Grimm) (06/21/91)
> Thanks Nigel -- Fortunately (or unfortunately as the case may be) I > find that I had the document in my unread files all along. Sorry to > bother you all with my untimely question. > > However, I was surprised (many of you out there will also be > surprised) that I was not offended with the draft, so I will not be > making any negative comments to my national body folks. > > I found the logic of it all to be rather good, and it does not mess up > the bit about the order of the OU elements. > > I must say though that it is not what I would have come up with, but > it looks OK to me. > > Best...\Stef Funny enough, that was exactly my feeling: When I first heard from J.Palme, that the ordering of the Orgunits is opposite to the rest of the attributes I felt a lot of pain. But when I looked into the draft document, it all looked logical and nice. I think, I could live with it. However, the lots of change of existing software to cope with that will be enormous. But isn't that what always happens during the development of standards to the "avantgarde"? Greetings --- Ruedger
Piet.Beertema@cwi.nl (06/21/91)
However, the lots of change of existing software to cope with that will be enormous. But isn't that what always happens during the development of standards to the "avantgarde"? OK for something you're doing research on, but not for something you're supposed to provide a service with. Piet
nbevan@ess.cs.ucl.ac.uk (Nigel Bevan) (06/21/91)
I would have thought that some minor changes to the parsing of the user interface were fairly minor in the context of a communications package? Since we have gathered that there are several incompatible conventions currently in use, perhaps it was time there was a standard?
Stef@ics.uci.edu (Einar Stefferud) (06/22/91)
More to the point of the problem with changing things at this point,
there are service providers and vendors with hundreds and thousands of
systems in the field that will need upgrading one way or another over
time.
As Piet noted, this is not research any more. As I like to note:
"Gee Toto, I don't think we are in Academia any more!"
While I am in here -- Does anyone have any idea as to how much use
will be made of the Terminal Identifier and the User Agent Numeric
Indentifier atributes of the ORADdress?
Extracting from the CCITT Draft text, I am referring to these two
specific ORAddress attributes:
There are 3 categories of attributes: those which may be used in
commonly-used O/R addresses (eg on business cards), those used in
physical delivery addresses, and other specialised attributes (network
address, user agent numeric ID and terminal identifier).
^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^
User Agent Numeric ID N-ID
Terminal Identifier T-ID
Some implementor has asked me this question, wondering whether to do
the work of enabling their entry now, or not. One problem I see is
that a user interface that prompts for all the odd attributes is going
to drive the users crazy! The regular atributes are more than enough
already!
Any comments will be welcome...\Stef/G=Peter/S=Varlien/OU=TRONDHEIM/O=ND ServiceTeam/PRMD=NORSK DATA/@noprmd.telemax.no (06/24/91)
Stef asks: "While I am in here -- Does anyone have any idea as to how much use will be made of the Terminal Identifier and the User Agent Numeric Indentifier attributes of the ORADdress?" User Agent Numeric Identifier I won't comment. Terminal Identifier appears from my reading of X.400/88 and X.402/88 intended to be paired with X.121 address when accessing "Telematic terminals" (i.e. Telex and Teletex) through an access unit. Telex answerbacks and Teletex terminal identifiers are specifically used as examples. I haven't actually seen this implemented, our ADMD here in Norway is currently using DDAs to address Telex subscribers through their AU. If anyone knows of a TTX AU, perhaps they can confirm that 2421-520147=NDTRDCTS is the same as X121=2421520147;T-ID=NDTRDCTS;C=?;ADMD=? Likewise, 55101 NDTRD N (Telex) should be X121=85655101;T-ID=NDTRDN; C=... (Country/ADMD in my examples as appropriate for addressing the AU in question. The TLX/TTX numbers are to test systems here, until my boss decides not to pay for them any longer...) Teletex hasn't been much of a success, I believe Germany has this largest installed base with about 10000 terminals. (The Norwegian TTX service will be shut down next year, it had about 200 subscribers before the PTT decided to throw in the towel.) Telex, however, is VERY wide spread. In the less developed parts of the world I've heard it often works better then the Telephone network (and thereby also better than Fax...). Conclusions: 1) Terminal-ID is only useful if there are AU's around that use it. 2) The user needn't be bothered with it unless he (she) has entered an X.121 address already. Regards, +---------------------------+------------------------------------------+ ! Peter Varlien ! X.400: C=no;ADMD=Telemax; ! ! Product Specialist MHS ! PRMD=Norsk Data;O=ND ServiceTeam; ! ! ND ServiceTeam ! OU=Trondheim S=Varlien;G=Peter ! ! (a division of Norsk Data)! Internet: Peter.Varlien@Trondheim. ! ! N-7004 Trondheim, Norway ! ND-ServiceTeam.Norsk-Data. ! ! 'phone: +47-7-921222 ! Telemax.no ! +---------------------------+------------------------------------------+
koorland@vancouver.osiware.bc.ca (Neil Koorland) (06/25/91)
> More to the point of the problem with changing things at this point, > there are service providers and vendors with hundreds and thousands of > systems in the field that will need upgrading one way or another over > time. As a vendor, HEAR, HEAR ! > While I am in here -- Does anyone have any idea as to how much use > will be made of the Terminal Identifier and the User Agent Numeric > Indentifier atributes of the ORADdress? > the work of enabling their entry now, or not. One problem I see is > that a user interface that prompts for all the odd attributes is going > to drive the users crazy! The regular atributes are more than enough > already! We have never come across users that use these attributes, but I don't think that supporting it means having to prompt for them every time. What about configurable products and user profiles ? Unfortunately, even leaving them out of the prompt won't stop your users from going crazy when they still have to provide input values for all the other attributes. Neil Koorland
kit@gateway.mitre.org (06/26/91)
Dialcom (aka BT Tymnet, aka BT North America) has supported for several years X.121 addressing for Telex and FAX message delivery from their X.400 and proprietary messaging service. I think they used the Terminal ID field for carrying the answerback string for the Telex recipient. Some FAX devices may also have answerback strings, though I haven't worked with them. (Of course, now BT NA is dropping their old mail system, and I do not know the capabilities of their new product line.) Kit Lueder. (The opinions stated here are my own, and do not reflect the position of my current or former employers.)
eskovgaa@cue.bc.ca (Erik Skovgaard) (06/26/91)
Most of the products out there only route on the Form 1, Var 1 (1988:
mnemonic) attributes, so I would guess, the other forms are not used
much. However, several PDAUs are now being installed, so it may be
worth supporting the Postal forms.
....Erik.