Syntax of A/V pairs was as follows:

[<TAB>][Space:Vendor:]Attribute[<SP>]=[<SP>][Type:]Value<LF>

New proposal for attribute spec part:

[[Space:]Vendor:]{Attribute[:tag]}

If only one colon is present, the spec is interpreted as Attribute:tag. In
order to specify the vendor, you have to specify the tag. Hm, that's not very
attractive. Using the numeric distinction is no good either, because we want
to be able to use numeric vendors and attributes.

Wether we interpret something as a tag may be dependent on what the dictionary
says, although it's quite a bit of a layering violation.

The main problems are:
	* don't make specifying tags mandatory if you want to specify a vendor	
	* backwards compatibility in the ASCII interface should be preserved
	* the use of a colon to specify a tag is preferred as it's a 'standard'

These are  conflicting. We can use all colons by using information from other
sources: 1. type (numeric/alphanumeric), 2. dictionary, or 3. use a different
delimiter after all. For the tag then that is, otherwise we break compati-
bility with existing ASCII modules.

Alternative idea: specify tags as follows:

	attribute:tag: 
or
	:attribute:tag:

and vendors as 

	vendor:attribute

Disadvantage: small difference between 88:1: = x and 88:1 := x -- and what 
would become of 88:1:=x ?

There's another problem: in most minimal form, an attribute could be a 
standalone number. If we only allow that on output, we loose the ability
to convert back and forth.

To further complicate matters, we have the req: and rep: prefixes, although
they can be tested as a whole.

Perhaps we can interpret :15 as an attribute and 15 as fifteen. An attribute
starts with its spec, prefix or colon.
