Re: street (was: more schema-08 notes)

[John McMeeking <jmcmeek@us.ibm.com>]

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