oidplusalarmingautosfxaysaliacalllibchecksum-toolscolormanagercryptochatcurrency_converterdecoderdelphiutilsdistributeddpcstudiodpg2fastphpfileformatsfilter_foundryforestgridgameht46f47_simulatorindexer_suiteipe_artfile_utilsjavautilsjumperlightgamelogviewermusikboxmystic_houseoidconverteroidinfo_apioidinfo_new_designpersonal-webbasephp_antispamphp_clientchallengephp_guestbookphp_utilsplumbersprependrecyclebinunitsimple_log_eventsokobanspacemissionstackmanuserdetect2uuid_mac_utilsvgwhoisvnagwebcounterwinbugtrackeryt_downloader

BlueGreycalmElegant

Català-Valencià – Catalan中文 – Chinese (Simplified)中文 – Chinese (Traditional)Česky – CzechDansk – DanishNederlands – DutchEnglish – EnglishSuomi – FinnishFrançais – FrenchDeutsch – Germanעברית – Hebrewहिंदी – HindiMagyar – HungarianBahasa Indonesia – IndonesianItaliano – Italian日本語 – Japanese한국어 – KoreanМакедонски – Macedonianमराठी – MarathiNorsk – NorwegianPolski – PolishPortuguês – PortuguesePortuguês – Portuguese (Brazil)Русский – RussianSlovenčina – SlovakSlovenščina – SlovenianEspañol – SpanishSvenska – SwedishTürkçe – TurkishУкраїнська – UkrainianOëzbekcha – Uzbek

Compare Revisions

• This comparison shows the changes necessary to convert path

  → /trunk_oldversion/_private/probleme @ 225

  → /trunk_oldversion/_private/probleme @ 226

  ↔ Reverse comparison

• Compare Path:	Rev

  With Path:	Rev

Regard whitespace Rev 225 → Rev 226

/trunk_oldversion/_private/probleme
0,0 → 1,9
es kann nicht garantiert werden dass die RA sich selbst felder definiert ohne die superior RA zu beachten (wie im vorherigen konzept von oiddb1 gelöst)
es wird vorausgesetzt dass ein whois server aufgesetzt werden kann
es ist unklar wie schreibender zugriff gewährt werden kann
es ist nicht möglich, geheime oids zu erzeugen, man kann nur die attribute geheim machen
wird rwhois angwandt, dann erfahren die superior nodes den token, der nicht für sie bestimmt ist