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

RE: MHS Schema



Kurt,

Kurt D. Zeilenga wrote:
> I think we should remove the MHS OR Address syntax from
> the "core" specification.  This syntax is dependent on
> RFC 1327.  RFC 1327 has been obsoleted by RFC 2156,
> presently a Proposed Standard.  However, RFC 2156 is
> nearly five years old and I don't see any viable effort
> to revise it for Draft Standard.

I raised this at the LDAPbis meeting. The only way to keep the
OR Address syntax in the core is to copy the specification of
its string encoding into the syntaxes draft. I really don't want
to do that. I don't think this syntax is used widely enough to
warrant it being in the core. I'll take it out of the syntaxes
draft for the next revision.
 
> Presentation Address syntax should also be removed.  It is
> dependent on RFC 1278, presently Informational.  As there
> is no viable effort to bring this specification onto the
> standards track, our dependency upon this specification
> must be cut.

We dealt with this syntax by drawing its string encoding into
the syntaxes draft. I would just as soon see it cut from the core.
Are the chairs ready to call consensus so I can rip it out ?

Regards,
Steven

> Likewise, the presentationAddressMatch rule,
> the 'presentationAddress' attribute type, and the
> 'applicationProcess' object class should be removed.
> 
> Also, as previously discussed, the protocol information
> syntax should be removed as having no defined LDAP string
> encoding.  Removing dependent elements, namely
> protocolInformationMatch rule, the protocolInformation
> attribute type are also necessary.
> 
> Also, supportedApplicationContext should be removed as
> its semantics is not well specified in RFC 2256 and it
> specificaiton should likely be kept with the specification
> of 'applicationProcess'.
> 
> Hence, I propose that the specification of these schema
> elements be removed from the revised LDAP "core" specification
> and, if desired, be progressed separately on an individual
> basis.
> 
> Comments?
> 
> Kurt
> 
>