- **Milestone**: future --> 4.5.FC
---
** [tickets:#23] IMM: SAF RDN limitation of 64 characters should be removed**
**Status:** unassigned
**Created:** Tue May 07, 2013 09:02 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue May 07, 2013 09:02 AM UTC
**Owner:** Anders Bjornerstedt
Migrated from:
http://devel.opensaf.org/ticket/2473
Request to emove the enforcement of the 64 byte limitation.
It restricts usability and flexibility of IMM.
The reason it exists can be found in the SAI-Overview document
under the section "4.3.9 Name Type". The motivation for it is
to reduce the risk of hitting the 256 byte limit on SaNameT.
If this change is introduced then we need to add to the
documentation on deviation from standard in the
OpneSAF_IMMSv_PR.
See also http://devel.opensaf.org/ticket/2475
====================================================
When installing some applications onto an OpenSAF cluster, there is a problem
because of the 64 character limitation on SaStringT (this includes the NULL
character).
When executing:
immadm -o 1 -p directoryPathExtension:SA_STRING_T:<package_name> swMId=1
The following error is logged:
osafimmnd[30005]: ERR_INVALID_PARAM: RDN attribute is too large: 65. Max length
is 64 for SaStringT
This is insufficient for any typical package.
---------------------------------------------------------------
There is no 64 byte limit on SaStringT.
There IS a 64 byte limit on the lenghts of the RDN attribute value,
when it is defined on the SaStringT type. Thiss is specified in the SAF
standard.
You can get arround the 64 byte limitation on RDN length by defining it on the
SaNameT type.
But the SaNameT type has a limit of 256 bytes (255 bytes if you want null
terminated strings).
This workaround (to avoid the 64 byte limit) is actually "cheating" unless the
object/class
represents a so-called association object. I wont get into details but the
SaNameT type
is supposed to be used only for holding DNs, not RDNs. Association objects have
the strange
property of using a DN as an RDN value.
The reason for the 64 byte limit on RDN values defined on SaStringT I think is
motivated
by an effort to keep down the length of DNs, to avoid hitting the 256 byte
limit.
Why SAF decided to use the fixed size SaNameT type in the first place you have
to ask
the SAF standardisers. In my opinion this limitation is one of the larger
mistakes made
by SAF. It is also not easy to change because the SaNameT type is used by
practically all
SAF services (not just the IMM).
We could think about some form of enhancement to get arround this, but it
impacts *all* SAF
APIs and the change needs to be more or less coordinated over all SAF services
for a
particular release.
--------------------------------------------------------------
Hans, I corrected the description since the statement "no convincing reason" is
sort of not the main point when talking about a sandard. Plus we know the reason
is to keep down the risk of hitting the 256 byte limit on SaNameT.
I would rather put it this way: Removing the 64 byte limit on RDN is in itself
a relaxation and as such should not cause any direct problems.
Some now think that the advantages of removing the 64 byte RDN limit outweigh
the disadvantage, i.e. increased risk of hitting the 256 byte limit.
The ACK/NACK on this enhancement is not just an ACK/NACK on the patch,
it is more fundamentally an ACK/NACK on the issue of OpenSAF departing from
SAF on this point.
-------------------------------------------------------------
There is actually a serious argument against this fix, which is valid as long as
the 256 byte limit on SaNameT/RDNs exists.
It goes like this.
The 64 byte limit on RDN is more likely to be hit during testing and
development,
than during production. More likely that is, than the 256 byte limit to be hit
during testing & development, even if the 64 byte RDN limit is dropped.
Hitting this limit during testing & development, will force the application to
redesign its RDN "template". This is "doable" if the problem is hit during
testing & development.
If the 256 byte limit is hit in production, then there is really no "fix"
that can be done. The only thing that can be done is to rename a one or more
objects in the tree. Something the operator not always can do.
--------------------------------------------------------------------
I think that for this ticket to be accepted, it needs to be accepted by the
OpenSAF TC.
If the OpenSAF TC decides that the advantages outweigh the risks (olitical and
practical)
for this ticket, then I would accept the patch.
An alternative is to postpone this fix untill we propose a new set of additions
to the IMM standard (as we did for A.2.11).
------------------------------------------------------------
There are quite a few "feature-enhancements" pending/awaiting standardization.
This proposal is changing or "deviating" from the SAF programming paradigm
itself.
My initial reaction is to suggest postponing this topic.
------------------------------------------------------------------
Postponing this for further study. Will not push the patch as of now.
------------------------------------------------------------------
One way to *reduce* problem of both the 256 byte DN limit and the 64 byte RDN
limit would
be for applications that are non SAF services to abandon the convention of
including the
RDN atribute name in the value of the RDN. Thus instead of creating RDN values
on the form
RdnAttributeName?=SomeValue?
the RDN value would just be:
SomeValue?
If we assume the parent DN was
"Z,Y,X"
then the newly created object would get the DN:
"SomeValue?,Z,Y,X".
This already works in the raw imm API.
But the imm-tools would need to be adapted to cope with the reduced RDN format.
This is because some imm-tools use the <rdn-attribute-name> =
<rdn-attribute-value>
both to determine which attribute is supposed to be the rdn and as the value.
There is actually no need for the '<RdnAttributeName?>=' to be part of the RDN
or the DN.
It is redundant inforamtion since the imm has the concept of class, defining
what the name
of the Rdn attribute is.
By contrast LDAP has no class concept. Instead it has the concept of attribute
types.
So in the LDAP case one has tp prefix the rdn value with the
attribute-type-name.
Note that removing the redundant '<RdnAttributeName?>=' from the RDN is what
also removes it
from the DN.
The real problem is the really the limited length of DNs.
The 64 byte limit on RDNs is derived from the DN limit.
There is no point in removing or increasing the RDN limit if the DN limit is
unchanged.
The SAF defined classes and objects need to stick to the standard naming
convention,
using this redundancy. But applications using OpenSAF are not bounf by any
standard
in the detailed naming scheme.
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
Android™ apps run on BlackBerry®10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
