I'm trying to create some new attrributes within ADAM instance - when 
entering the X500 OID I've entered 1.2.36.825753556.1 (36=Australia, 
825753556=Partial Tax Office ABN missing 51) however I always get an error 
saying a parameter is incorrect. If I change to OID to 1.2.36.123456789.1 it 
works I think all over OID would work too but 
http://www.alvestrand.no/objectid/1.2.36.html states that 'Australian 
companies may use their Australian Company Number (excluding leading zeros) 
to formulate their OID'

It would seem that's true for the Tax Office. Is there any rules as to what 
constitutes valid OIDs or is there something wrong with ADAM?

Regards
Robert.

AD and ADAM require that each part of the OID is a DWORD. In your case, it's 
more than a DWORD. AFAIK, nobody really uses OIDs to locate their owner, so 
you don't really need to follow that standard. I suggest you contact MS and 
get yourself another OID prefix. There's a page on MSDN that explains how to 
request an OID prefix.

-- 
Dmitri Gavrilov
SDE, DS Admin eXperience

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Robert Rolls"  wrote in message 
news:Of3N8hMcFHA.3864@TK2MSFTNGP10.phx.gbl...
> I'm trying to create some new attrributes within ADAM instance - when 
> entering the X500 OID I've entered 1.2.36.825753556.1 (36=Australia, 
> 825753556=Partial Tax Office ABN missing 51) however I always get an error 
> saying a parameter is incorrect. If I change to OID to 1.2.36.123456789.1 
> it works I think all over OID would work too but 
> http://www.alvestrand.no/objectid/1.2.36.html states that 'Australian 
> companies may use their Australian Company Number (excluding leading 
> zeros) to formulate their OID'
>
> It would seem that's true for the Tax Office. Is there any rules as to 
> what constitutes valid OIDs or is there something wrong with ADAM?
>
> Regards
> Robert.
>

So AD and ADAM don't follow the OID naming standard for 1.2.36 ? and rather 
than choose a random number (which one day could collide) I have to contact 
MS for a OID prefix LOL, Thanks for that. It's a shame as we (the client) 
issue digital certificates 120+/- publicaly available that have our own OIDs 
defined within for extended attributes so in our infinite wisdom we'd use 
the company standard oh well maybe next time.

Robert.

"Dmitri Gavrilov [MSFT]"  wrote in message 
news:uZy8m$XcFHA.2420@TK2MSFTNGP15.phx.gbl...
> AD and ADAM require that each part of the OID is a DWORD. In your case, 
> it's more than a DWORD. AFAIK, nobody really uses OIDs to locate their 
> owner, so you don't really need to follow that standard. I suggest you 
> contact MS and get yourself another OID prefix. There's a page on MSDN 
> that explains how to request an OID prefix.
>
> -- 
> Dmitri Gavrilov
> SDE, DS Admin eXperience
>
> This posting is provided "AS IS" with no warranties, and confers no 
> rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
> "Robert Rolls"  wrote in message 
> news:Of3N8hMcFHA.3864@TK2MSFTNGP10.phx.gbl...
>> I'm trying to create some new attrributes within ADAM instance - when 
>> entering the X500 OID I've entered 1.2.36.825753556.1 (36=Australia, 
>> 825753556=Partial Tax Office ABN missing 51) however I always get an 
>> error saying a parameter is incorrect. If I change to OID to 
>> 1.2.36.123456789.1 it works I think all over OID would work too but 
>> http://www.alvestrand.no/objectid/1.2.36.html states that 'Australian 
>> companies may use their Australian Company Number (excluding leading 
>> zeros) to formulate their OID'
>>
>> It would seem that's true for the Tax Office. Is there any rules as to 
>> what constitutes valid OIDs or is there something wrong with ADAM?
>>
>> Regards
>> Robert.
>>
>
>

Joe Richards just corrected me (thanks Joe!), I miscounted the digits. This 
number actually fits into DWORD.

Can you get the exact error message? Try importing the attribute either with 
LDIFDE or LDP, and tell me what the extended server error is.

-- 
Dmitri Gavrilov
SDE, DS Admin eXperience

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Robert Rolls"  wrote in message 
news:ez78qCfcFHA.2212@TK2MSFTNGP14.phx.gbl...
> So AD and ADAM don't follow the OID naming standard for 1.2.36 ? and 
> rather than choose a random number (which one day could collide) I have to 
> contact MS for a OID prefix LOL, Thanks for that. It's a shame as we (the 
> client) issue digital certificates 120+/- publicaly available that have 
> our own OIDs defined within for extended attributes so in our infinite 
> wisdom we'd use the company standard oh well maybe next time.
>
> Robert.
>
> "Dmitri Gavrilov [MSFT]"  wrote in message 
> news:uZy8m$XcFHA.2420@TK2MSFTNGP15.phx.gbl...
>> AD and ADAM require that each part of the OID is a DWORD. In your case, 
>> it's more than a DWORD. AFAIK, nobody really uses OIDs to locate their 
>> owner, so you don't really need to follow that standard. I suggest you 
>> contact MS and get yourself another OID prefix. There's a page on MSDN 
>> that explains how to request an OID prefix.
>>
>> -- 
>> Dmitri Gavrilov
>> SDE, DS Admin eXperience
>>
>> This posting is provided "AS IS" with no warranties, and confers no 
>> rights.
>> Use of included script samples are subject to the terms specified at
>> http://www.microsoft.com/info/cpyright.htm
>>
>> "Robert Rolls"  wrote in message 
>> news:Of3N8hMcFHA.3864@TK2MSFTNGP10.phx.gbl...
>>> I'm trying to create some new attrributes within ADAM instance - when 
>>> entering the X500 OID I've entered 1.2.36.825753556.1 (36=Australia, 
>>> 825753556=Partial Tax Office ABN missing 51) however I always get an 
>>> error saying a parameter is incorrect. If I change to OID to 
>>> 1.2.36.123456789.1 it works I think all over OID would work too but 
>>> http://www.alvestrand.no/objectid/1.2.36.html states that 'Australian 
>>> companies may use their Australian Company Number (excluding leading 
>>> zeros) to formulate their OID'
>>>
>>> It would seem that's true for the Tax Office. Is there any rules as to 
>>> what constitutes valid OIDs or is there something wrong with ADAM?
>>>
>>> Regards
>>> Robert.
>>>
>>
>>
>
>

Here's what I get:

Importing directory from file "testattr.ldf"
Loading entries.
Add error on line 1: No Such Attribute
The server side error is: 0x57 The parameter is incorrect.
The extended server error is:
00000057: LdapErr: DSID-0C090B3D, comment: Error in attribute conversion 
operation, data 0, vece
0 entries modified successfully.

that's on

dsaVersionString: 1.1.3790.1939 (dnsrv_r2_beta2.050413-1957)


Lee Flight

"Dmitri Gavrilov [MSFT]"  wrote in message 
news:uoOyW3qcFHA.616@TK2MSFTNGP12.phx.gbl...
> Joe Richards just corrected me (thanks Joe!), I miscounted the digits. 
> This number actually fits into DWORD.
>
> Can you get the exact error message? Try importing the attribute either 
> with LDIFDE or LDP, and tell me what the extended server error is.
>
> -- 
> Dmitri Gavrilov
> SDE, DS Admin eXperience
>
> This posting is provided "AS IS" with no warranties, and confers no 
> rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
> "Robert Rolls"  wrote in message 
> news:ez78qCfcFHA.2212@TK2MSFTNGP14.phx.gbl...
>> So AD and ADAM don't follow the OID naming standard for 1.2.36 ? and 
>> rather than choose a random number (which one day could collide) I have 
>> to contact MS for a OID prefix LOL, Thanks for that. It's a shame as we 
>> (the client) issue digital certificates 120+/- publicaly available that 
>> have our own OIDs defined within for extended attributes so in our 
>> infinite wisdom we'd use the company standard oh well maybe next time.
>>
>> Robert.
>>
>> "Dmitri Gavrilov [MSFT]"  wrote in message 
>> news:uZy8m$XcFHA.2420@TK2MSFTNGP15.phx.gbl...
>>> AD and ADAM require that each part of the OID is a DWORD. In your case, 
>>> it's more than a DWORD. AFAIK, nobody really uses OIDs to locate their 
>>> owner, so you don't really need to follow that standard. I suggest you 
>>> contact MS and get yourself another OID prefix. There's a page on MSDN 
>>> that explains how to request an OID prefix.
>>>
>>> -- 
>>> Dmitri Gavrilov
>>> SDE, DS Admin eXperience
>>>
>>> This posting is provided "AS IS" with no warranties, and confers no 
>>> rights.
>>> Use of included script samples are subject to the terms specified at
>>> http://www.microsoft.com/info/cpyright.htm
>>>
>>> "Robert Rolls"  wrote in message 
>>> news:Of3N8hMcFHA.3864@TK2MSFTNGP10.phx.gbl...
>>>> I'm trying to create some new attrributes within ADAM instance - when 
>>>> entering the X500 OID I've entered 1.2.36.825753556.1 (36=Australia, 
>>>> 825753556=Partial Tax Office ABN missing 51) however I always get an 
>>>> error saying a parameter is incorrect. If I change to OID to 
>>>> 1.2.36.123456789.1 it works I think all over OID would work too but 
>>>> http://www.alvestrand.no/objectid/1.2.36.html states that 'Australian 
>>>> companies may use their Australian Company Number (excluding leading 
>>>> zeros) to formulate their OID'
>>>>
>>>> It would seem that's true for the Tax Office. Is there any rules as to 
>>>> what constitutes valid OIDs or is there something wrong with ADAM?
>>>>
>>>> Regards
>>>> Robert.
>>>>
>>>
>>>
>>
>>
>
>

No problem Dmitri. Honest mistake.

Robert:

A few comments I wanted to make

1. If you can, post the LDF info for the attribute you are trying to create so 
myself/others can attempt it as well.

2. Don't take personally what D originally said about the DWORD thing. I poked 
around and I couldn't find where ITU (I think that is where the standard came 
from) indicated how to implement OID handling, specifically the size of the 
numeric portions between the dot separators. Just that it was digits with dots. 
I.E. I don't think the size of digits is specified.

Possibly MS could be chastised for implementing the fields with DWORD 
limitations but probably that was done for efficiency and speed of processing. I 
really don't expect that MS purposely looked to avoid supporting any given OID.

The other options would have to always handled the individual fields as strings 
or as 64 bit ints (which would still have limits, just larger ones) but they 
would have impacted perf and data size in terms of anything dealing with the 
fields. Additionally 64 bit ints and strings can be more painful to deal with in 
code and more apt to be involved with mistakes.

3. Finally MS isn't the only place you can get OIDs that work with AD. Dmitri 
offered it up because it is an easy free mechanism and involves something you 
should do anyway, registering your OID and a schema prefix. This way you can get 
a combination more likely to be unique. Anyone doing schema extensions in AD 
should check with MS to verify registration of the OID and prefix so they don't 
run into a case of someone just making something up. There have been several 
collisions out there and this is a way to help avoid them.

    joe







--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Dmitri Gavrilov [MSFT] wrote:
> Joe Richards just corrected me (thanks Joe!), I miscounted the digits. This 
> number actually fits into DWORD.
> 
> Can you get the exact error message? Try importing the attribute either with 
> LDIFDE or LDP, and tell me what the extended server error is.
>

Thanks Lee and Joe for following up. I was wrong again. The biggest OID 
element we support is 0x0FFFFFFF = 268435455. So, the OID below cannot be 
imported into AD or into ADAM.

I really did not mean to offend anybody, I am just telling how it is coded. 
And I am trying to suggest a workaround.

-- 
Dmitri Gavrilov
SDE, DS Admin eXperience

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Lee Flight" <lef@le.ac.uk-nospam> wrote in message 
news:ev$C$HscFHA.1036@tk2msftngp13.phx.gbl...
> Here's what I get:
>
> Importing directory from file "testattr.ldf"
> Loading entries.
> Add error on line 1: No Such Attribute
> The server side error is: 0x57 The parameter is incorrect.
> The extended server error is:
> 00000057: LdapErr: DSID-0C090B3D, comment: Error in attribute conversion 
> operation, data 0, vece
> 0 entries modified successfully.
>
> that's on
>
> dsaVersionString: 1.1.3790.1939 (dnsrv_r2_beta2.050413-1957)
>
>
> Lee Flight
>
> "Dmitri Gavrilov [MSFT]"  wrote in message 
> news:uoOyW3qcFHA.616@TK2MSFTNGP12.phx.gbl...
>> Joe Richards just corrected me (thanks Joe!), I miscounted the digits. 
>> This number actually fits into DWORD.
>>
>> Can you get the exact error message? Try importing the attribute either 
>> with LDIFDE or LDP, and tell me what the extended server error is.
>>
>> -- 
>> Dmitri Gavrilov
>> SDE, DS Admin eXperience
>>
>> This posting is provided "AS IS" with no warranties, and confers no 
>> rights.
>> Use of included script samples are subject to the terms specified at
>> http://www.microsoft.com/info/cpyright.htm
>>
>> "Robert Rolls"  wrote in message 
>> news:ez78qCfcFHA.2212@TK2MSFTNGP14.phx.gbl...
>>> So AD and ADAM don't follow the OID naming standard for 1.2.36 ? and 
>>> rather than choose a random number (which one day could collide) I have 
>>> to contact MS for a OID prefix LOL, Thanks for that. It's a shame as we 
>>> (the client) issue digital certificates 120+/- publicaly available that 
>>> have our own OIDs defined within for extended attributes so in our 
>>> infinite wisdom we'd use the company standard oh well maybe next time.
>>>
>>> Robert.
>>>
>>> "Dmitri Gavrilov [MSFT]"  wrote in message 
>>> news:uZy8m$XcFHA.2420@TK2MSFTNGP15.phx.gbl...
>>>> AD and ADAM require that each part of the OID is a DWORD. In your case, 
>>>> it's more than a DWORD. AFAIK, nobody really uses OIDs to locate their 
>>>> owner, so you don't really need to follow that standard. I suggest you 
>>>> contact MS and get yourself another OID prefix. There's a page on MSDN 
>>>> that explains how to request an OID prefix.
>>>>
>>>> -- 
>>>> Dmitri Gavrilov
>>>> SDE, DS Admin eXperience
>>>>
>>>> This posting is provided "AS IS" with no warranties, and confers no 
>>>> rights.
>>>> Use of included script samples are subject to the terms specified at
>>>> http://www.microsoft.com/info/cpyright.htm
>>>>
>>>> "Robert Rolls"  wrote in message 
>>>> news:Of3N8hMcFHA.3864@TK2MSFTNGP10.phx.gbl...
>>>>> I'm trying to create some new attrributes within ADAM instance - when 
>>>>> entering the X500 OID I've entered 1.2.36.825753556.1 (36=Australia, 
>>>>> 825753556=Partial Tax Office ABN missing 51) however I always get an 
>>>>> error saying a parameter is incorrect. If I change to OID to 
>>>>> 1.2.36.123456789.1 it works I think all over OID would work too but 
>>>>> http://www.alvestrand.no/objectid/1.2.36.html states that 'Australian 
>>>>> companies may use their Australian Company Number (excluding leading 
>>>>> zeros) to formulate their OID'
>>>>>
>>>>> It would seem that's true for the Tax Office. Is there any rules as to 
>>>>> what constitutes valid OIDs or is there something wrong with ADAM?
>>>>>
>>>>> Regards
>>>>> Robert.
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Hi Joe

I had a look around too before I posted the error, I could not find a public
copy of the relevant ITU document. I found a related document in which
ITU give guidance about the use of the country code but nothing about
what usage further along the arc. I actually came to the, probably
erroneous conclusion that there was a limit of the kind that AD/ADAM
implement, as the only examples of numbers larger that I could find
in any of the public OID databases were no longer in use or marked as
registered in error.

Maybe there's an ITU mailing list somewhere...

Lee Flight

"Joe Richards [MVP]"  wrote in message 
news:uSZwWlscFHA.3396@TK2MSFTNGP10.phx.gbl...

>  I poked around and I couldn't find where ITU (I think that is where the 
> standard came from) indicated how to implement OID handling, specifically 
> the size of the numeric portions between the dot separators. Just that it 
> was digits with dots. I.E. I don't think the size of digits is specified.

I also looked, and this is the only doc I could find:
http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf
See section 31. It basically says it's a "number", whatever it means.

-- 
Dmitri Gavrilov
SDE, DS Admin eXperience

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Lee Flight" <lef@le.ac.uk-nospam> wrote in message 
news:OjKqFm3cFHA.2520@TK2MSFTNGP09.phx.gbl...
> Hi Joe
>
> I had a look around too before I posted the error, I could not find a 
> public
> copy of the relevant ITU document. I found a related document in which
> ITU give guidance about the use of the country code but nothing about
> what usage further along the arc. I actually came to the, probably
> erroneous conclusion that there was a limit of the kind that AD/ADAM
> implement, as the only examples of numbers larger that I could find
> in any of the public OID databases were no longer in use or marked as
> registered in error.
>
> Maybe there's an ITU mailing list somewhere...
>
> Lee Flight
>
> "Joe Richards [MVP]"  wrote in message 
> news:uSZwWlscFHA.3396@TK2MSFTNGP10.phx.gbl...
>
>>  I poked around and I couldn't find where ITU (I think that is where the 
>> standard came from) indicated how to implement OID handling, specifically 
>> the size of the numeric portions between the dot separators. Just that it 
>> was digits with dots. I.E. I don't think the size of digits is specified.
>
>

Oy!

3 and half bytes? 7 nibbles?

That seems unusual to chop it off there.

I expect there must be some unusual story involved...

So has this made it into the "to be looked at to be possibly corrected in the 
future" category? Sounds like Australia could take it on a chin for this one. 
Since they are using numbers already registered, I expect that they don't 
normally register  in other places since they are already guaranteed unique.

Anyone know where OpenLdap, iPlanet, eDirectory and the others break at?




--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Dmitri Gavrilov [MSFT] wrote:
> Thanks Lee and Joe for following up. I was wrong again. The biggest OID 
> element we support is 0x0FFFFFFF = 268435455. So, the OID below cannot be 
> imported into AD or into ADAM.
> 
> I really did not mean to offend anybody, I am just telling how it is coded. 
> And I am trying to suggest a workaround.
>

I just tried SunOne (iPlanet) and it happily swallowed the OID
in the original post. As for OpenLDAP, well we just need to examine
the source... :-)

Lee Flight

"Joe Richards [MVP]"  wrote in message 
news:u8uvna4cFHA.1020@TK2MSFTNGP10.phx.gbl...
> Oy!
>
> 3 and half bytes? 7 nibbles?
>
> That seems unusual to chop it off there.
>
> I expect there must be some unusual story involved...
>
> So has this made it into the "to be looked at to be possibly corrected in 
> the future" category? Sounds like Australia could take it on a chin for 
> this one. Since they are using numbers already registered, I expect that 
> they don't normally register  in other places since they are already 
> guaranteed unique.
>
> Anyone know where OpenLdap, iPlanet, eDirectory and the others break at?
>
>
>
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
> Dmitri Gavrilov [MSFT] wrote:
>> Thanks Lee and Joe for following up. I was wrong again. The biggest OID 
>> element we support is 0x0FFFFFFF = 268435455. So, the OID below cannot be 
>> imported into AD or into ADAM.
>>
>> I really did not mean to offend anybody, I am just telling how it is 
>> coded. And I am trying to suggest a workaround.
>>

Yeah... I'll file the bug. This has something to do with the way we encode 
OID prefixes. Sorry...

-- 
Dmitri Gavrilov
SDE, DS Admin eXperience

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Joe Richards [MVP]"  wrote in message 
news:u8uvna4cFHA.1020@TK2MSFTNGP10.phx.gbl...
> Oy!
>
> 3 and half bytes? 7 nibbles?
>
> That seems unusual to chop it off there.
>
> I expect there must be some unusual story involved...
>
> So has this made it into the "to be looked at to be possibly corrected in 
> the future" category? Sounds like Australia could take it on a chin for 
> this one. Since they are using numbers already registered, I expect that 
> they don't normally register  in other places since they are already 
> guaranteed unique.
>
> Anyone know where OpenLdap, iPlanet, eDirectory and the others break at?
>
>
>
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
> Dmitri Gavrilov [MSFT] wrote:
>> Thanks Lee and Joe for following up. I was wrong again. The biggest OID 
>> element we support is 0x0FFFFFFF = 268435455. So, the OID below cannot be 
>> imported into AD or into ADAM.
>>
>> I really did not mean to offend anybody, I am just telling how it is 
>> coded. And I am trying to suggest a workaround.
>>

Cool thanks D.

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Dmitri Gavrilov [MSFT] wrote:
> Yeah... I'll file the bug. This has something to do with the way we encode 
> OID prefixes. Sorry...
>

If I knew how to create the LDF I surely would but the OID I'm trying to 
create is 1.2.36.824753556.1 Which is the last night digits of the 
Australian Taxation Offices' ABN complete is 51.824.753.556 the name is 
ato-ClientAccessProfile.

The link relevant to using ABN (Australian Business numbers) is 
http://www.alvestrand.no/objectid/1.2.36.html other relavant info regarding 
the use of ABN's within certificates is something called ABN-DSC 
http://www.verisign.com.au/gatekeeper/abndsc.shtml

Thanks to all
Robert.

"Joe Richards [MVP]"  wrote in message 
news:uSZwWlscFHA.3396@TK2MSFTNGP10.phx.gbl...
> No problem Dmitri. Honest mistake.
>
> Robert:
>
> A few comments I wanted to make
>
> 1. If you can, post the LDF info for the attribute you are trying to 
> create so myself/others can attempt it as well.
>
> 2. Don't take personally what D originally said about the DWORD thing. I 
> poked around and I couldn't find where ITU (I think that is where the 
> standard came from) indicated how to implement OID handling, specifically 
> the size of the numeric portions between the dot separators. Just that it 
> was digits with dots. I.E. I don't think the size of digits is specified.
>
> Possibly MS could be chastised for implementing the fields with DWORD 
> limitations but probably that was done for efficiency and speed of 
> processing. I really don't expect that MS purposely looked to avoid 
> supporting any given OID.
>
> The other options would have to always handled the individual fields as 
> strings or as 64 bit ints (which would still have limits, just larger 
> ones) but they would have impacted perf and data size in terms of anything 
> dealing with the fields. Additionally 64 bit ints and strings can be more 
> painful to deal with in code and more apt to be involved with mistakes.
>
> 3. Finally MS isn't the only place you can get OIDs that work with AD. 
> Dmitri offered it up because it is an easy free mechanism and involves 
> something you should do anyway, registering your OID and a schema prefix. 
> This way you can get a combination more likely to be unique. Anyone doing 
> schema extensions in AD should check with MS to verify registration of the 
> OID and prefix so they don't run into a case of someone just making 
> something up. There have been several collisions out there and this is a 
> way to help avoid them.
>
>    joe
>
>
>
>
>
>
>
> --
> Joe Richards Microsoft MVP Windows Server Directory Services
> www.joeware.net
>
>
> Dmitri Gavrilov [MSFT] wrote:
>> Joe Richards just corrected me (thanks Joe!), I miscounted the digits. 
>> This number actually fits into DWORD.
>>
>> Can you get the exact error message? Try importing the attribute either 
>> with LDIFDE or LDP, and tell me what the extended server error is.
>>

Robert, you will notice a post from Dmitri above where he came back and 
indicated that a full DWORD is not used, instead only 3.5 bytes are used which 
is preventing this from work. Unfortunately that will prevent any individual 
piece of the OID from being larger than 268435455.

There is also discussion about what the definition really is and it doesn't seem 
anyone can find anything better than a number which is pretty nebulous. 
Obviously implementation details are going to vary by vendor when it isn't 
specifically defined. Dmitri has filed a bug on it but I wouldn't expect any 
real change here until Longhorn, if then, unless some very large customers put 
some weight behind this issue and bump the priority. However, it really all 
depends on how difficult it will be to bump up the size of integer it will take 
or maybe look into some other mechanism that will support any value. They will 
have to investigate it and do what makes sense for everyone involved.

   joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Robert Rolls wrote:
> If I knew how to create the LDF I surely would but the OID I'm trying to 
> create is 1.2.36.824753556.1 Which is the last night digits of the 
> Australian Taxation Offices' ABN complete is 51.824.753.556 the name is 
> ato-ClientAccessProfile.
> 
> The link relevant to using ABN (Australian Business numbers) is 
> http://www.alvestrand.no/objectid/1.2.36.html other relavant info regarding 
> the use of ABN's within certificates is something called ABN-DSC 
> http://www.verisign.com.au/gatekeeper/abndsc.shtml
> 
> Thanks to all
> Robert.
> 
> "Joe Richards [MVP]"  wrote in message 
> news:uSZwWlscFHA.3396@TK2MSFTNGP10.phx.gbl...
> 
>>No problem Dmitri. Honest mistake.
>>
>>Robert:
>>
>>A few comments I wanted to make
>>
>>1. If you can, post the LDF info for the attribute you are trying to 
>>create so myself/others can attempt it as well.
>>
>>2. Don't take personally what D originally said about the DWORD thing. I 
>>poked around and I couldn't find where ITU (I think that is where the 
>>standard came from) indicated how to implement OID handling, specifically 
>>the size of the numeric portions between the dot separators. Just that it 
>>was digits with dots. I.E. I don't think the size of digits is specified.
>>
>>Possibly MS could be chastised for implementing the fields with DWORD 
>>limitations but probably that was done for efficiency and speed of 
>>processing. I really don't expect that MS purposely looked to avoid 
>>supporting any given OID.
>>
>>The other options would have to always handled the individual fields as 
>>strings or as 64 bit ints (which would still have limits, just larger 
>>ones) but they would have impacted perf and data size in terms of anything 
>>dealing with the fields. Additionally 64 bit ints and strings can be more 
>>painful to deal with in code and more apt to be involved with mistakes.
>>
>>3. Finally MS isn't the only place you can get OIDs that work with AD. 
>>Dmitri offered it up because it is an easy free mechanism and involves 
>>something you should do anyway, registering your OID and a schema prefix. 
>>This way you can get a combination more likely to be unique. Anyone doing 
>>schema extensions in AD should check with MS to verify registration of the 
>>OID and prefix so they don't run into a case of someone just making 
>>something up. There have been several collisions out there and this is a 
>>way to help avoid them.
>>
>>   joe
>>
>>
>>
>>
>>
>>
>>
>>--
>>Joe Richards Microsoft MVP Windows Server Directory Services
>>www.joeware.net
>>
>>
>>Dmitri Gavrilov [MSFT] wrote:
>>
>>>Joe Richards just corrected me (thanks Joe!), I miscounted the digits. 
>>>This number actually fits into DWORD.
>>>
>>>Can you get the exact error message? Try importing the attribute either 
>>>with LDIFDE or LDP, and tell me what the extended server error is.
>>>
> 
> 
>

Joe Richards [MVP] wrote:
> 
> Anyone know where OpenLdap, iPlanet, eDirectory and the others break at?

Added the OID 1.2.36.824753556.1 to subschema of OpenLDAP 2.3.4 and
created an entry without any problem.

Ciao, Michael.