[Date Prev][Date Next] [Chronological] [Thread] [Top]

street (was: more schema-08 notes)



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