RFC 2256 truncated the X.520 definitions quite a bit, and as a result I
believe you are misusing these attributes. The RFC (and the draft
replacement) does refer to the original documents, but ...
Maybe we should incorporate more of the text from X.520 (or other sources)?
From X.520 1993:
5.3.4 Street Adress
The Street Address attribute type specifies a site for the local
distribution and physical delivery in a postal address, i.e.
the street name, place, avenue, and the house number. When used as a
component of a directory name, it identifies the
street address at which the named object is located or with which it is
associated in some other important way.
An attribute value for Street Address is a string, e.g. "Arnulfstraße 60".
5.6.1 Postal Address
The Postal Address attribute type specifies the address information
required for the physical delivery of postal
messages by the postal authority to the named object.
An attribute value for Postal Address will be typically composed of
selected attributes from the MHS Unformatted
Postal O/R Address version 1 according to CCITT Rec. F.401 and limited to 6
lines of 30 characters each, including
a Postal Country Name. Normally the information contained in such an
address could include an addressee's name,
street address, city, state or province, postal code and possibly a Post
Office Box number depending on the specific
requirements of the named object.
5.6.2 Postal Code
The Postal Code attribute type specifies the postal code of the named
object. If this attribute value is present it will
be part of the object's postal address.
John McMeeking
Hallvard B Furuseth wrote on 03/30/2005 08:56:28 AM:
Andrew Sciberras writes:
Hi Hallvard,
Section 2.34, street, could use an example with ", " between
components,
to distinguish it from attrs with Postal Address syntax. I've seen
these syntaxes being confused in both directions.
(...)
The street attribute type is intended for a different usage than the
attribute types that use the Postal Address syntax.
Lets take this address as an example (Just something I grabbed from the
IETF webpage):
Minneapolis Hilton and Towers
1001 Marquette Avenue
Minneapolis, MN 55403 USA
If you wanted to represent this address in its entirety, then you
would use an attribute with a Postal Address syntax.
Well, our site's directory doesn't, and we are not alone. We'd rather
use a well-known attribute than invent our own which only our own
clients would know about. For that matter, our data source for street
is harder for a program to parse. It's partly free form and maintaining
it gets lower priority than the postalAddress source: People complain if
the postal address is wrong, since they'd lose snail mail.
I don't see how you can draw a comparison between this representation
of an address and what 'street' has to offer.
street and postalAddress contain similar data, so people sometimes treat
them the same way. That is pretty "obvious", after all. So I've seen
streets with '$' in the LDAP directory, and clients that break up street
addresses at '$'s.
The intention of 'street' would be to hold the following value:
"1001 Marquette Avenue"
And, 'st' would be: "Minneapolis"
And 'postalCode' would be: "55403"
Not at our site. postalCode, if we used it, would be the postal code of
the postal address. Usually that is a postbox and the street address
has another postal code. So street is e.g. "Research Street 3, 0373
OSLO" or "Admin. building, Problem street 7, 0313 OSLO" (in Norwegian).
That fits the description of street:
physical addresses of the object to which the entry corresponds, such
as an address for package delivery.
Oslo is big enough that omitting the postal code would not be a good
idea for package delivery.
So, I guess my point is, I don't believe that there should be an
example
with ", " to separate components, when the attribute type isn't really
designed to hold multiple components within a single value.
It's true it's not designed for multiple components. I should have said
that if one wants to stuff multiple components into it, the natural way
is with ", ". Now that I think of it, I suppose CRLF would be another
way but I haven't seen that usage.
--
Hallvard