Vorlage Diskussion:RFC-Internet

Wikidata

In Wikidata sind (alle?) RFCs als Datenobjekte angelegt. Dort sind alle Stammdaten wie Titel, Autor und Veröffentlichungsdatum als Aussagen hinterlegt. Beispiel für RFC 1234: d:Q47462012. Ist es möglich die Aussagen direkt aus Wikidata heranzuziehen? --Fomafix (Diskussion) 10:21, 12. Aug. 2019 (CEST)

Gehen wird so etwas sicherlich irgendwie. Wer das haben möchte muss sich dann auch um alles kümmern, ich habe die jetzt nur deshalb angelegt, weil es zu Darstellungsfehlern kommen könnte, wenn jemand direkt ein RFC 1234 in einen Vorlagenparameter setzt, der als Linktitel dient = Link in Link.

→Hilfe:Wikidata/Daten aus Wikidata beziehen

Ich fasse aber Wikidataeinbindungssyntax nicht an. --Liebe Grüße, Lómelinde Diskussion 12:20, 12. Aug. 2019 (CEST)

Theoretisch ginge sowas vermutlich.

Allerdings müsste für die Vorlage erstmal ein Algorithmus geschrieben werden, um anhand der RFC-Nummer das Datenobjekt herauszufinden, und falls ein solches gefunden würde, dann dieses in der momentanen Darstellung zur Ergänzung nutzen, falls bisher was fehlte.

Die bekannten Prozeduren gehen davon aus, dass der gesamte Artikel mit einem Datenobjekt verknüpft wäre, und ermitteln dann Eigenschaften zum aktuellen Lemma. Eine RFC-Zitation kann jedoch in beliebigen Seiten beliebig oft auftreten.

Was sicher nicht passieren wird, ist als Vorlagenparameter die herausgesuchte Q-Nummer anzugeben.

Die Informationen sind statisch; bei einem einmal veröffentlichten RFC ändert sich nie wieder was an den Stammdaten, und damit besteht keine Notwendigkeit für eine ständige Aktualisierung aus Wikidata.

Wenn das allerdings in unserem Quelltext insbesondere mit dem Titel statisch im Klartext drinsteht, so dass Zahlendreher und inhaltliche Verwechslungen ausgeschlossen oder schnell aufgeklärt werden können, dann ist das für unsere Zitationen optimal.

Autoren sind recht nachrangig, weil nach den Größen der ersten Generation kamen eigentlich nur noch Angestellte irgendwelcher Konzerne, die das mal im Auftrag in ihrer Arbeitszeit schrieben.

Die Plausibilität der Datumsangaben ließe sich eines Tages über ein Wartungsskript herausfinden, denn die streng monotone Anreihung der RFC muss bei gleicher Nummer gleiches Datum und ansonsten monotone Abfolge ergeben.

Der mit der Einbindung hinterlegte Titel ist verwechslungssicher; in der RFC-Nummer könnte sich schon der erste Zahlendreher eingeschlichen haben, und das Q-Zeugs kann sonstwas für Resultate liefern. Eignet sich allenfalls zum gelegentlichen automatischen Abgleich auf Konsistenz.

VG --PerfektesChaos 12:26, 12. Aug. 2019 (CEST)

Update[d|s], Obsoletes

1. RFCs (bspw. RFC 3986) können folgende Felder enthalten:

• Updated by (hier Aktualisierung / Updated)
• Updates
• Obsoletes (hier Ersetzt / Obsoletes)

Das heißt, die Info für Updates kann in der Vorlage derzeit nicht angegeben werden.

2. Jedes der oben genannten Felder kann mehr als eine Referenz enthalten. In der Vorlage wird bei Angabe von bspw. |Obsoletes=2732, 2396, 1808 aber nur die erste verlinkt. Man kann das zwar mit |Obsoletes=2732, RFC 2396, RFC 1808 umgehen, aber das muss man erst mal wissen (bzw. so wie ich auf die Idee kommen, das auszuprobieren, wenn die erste, naheliegendere Variante nicht das tut, was man erst mal erhofft).

Solange die Vorlage nicht dahingehend angepasst ist (was, so wie ich meine, nicht so schnell geschehen wird), wäre es vorteilhaft, diesen Workaround in der Doku zu erwähnen.

Siehe dazu entsprechende Verwendung in Query-String#Einzelnachweise. --Geri, ✉  12:25, 27. Nov. 2019 (CET)

Dein „Workaround“ kann nicht dauerhaft funktionieren und ist deshalb auch nicht erwünscht.

Die Vorlage wurde bereits im Vorgriff auf nach-magische Zeiten eingerichtet.

Die Parameter fordern je exakt eine Nummer; also ausschließlich Ziffern. Dein Vorschlag oder selbst eine Leerzeichen-getrennte Liste von Zahlen würde die beabsichtigte Gültigkeitsregel brechen.

Wir sind nicht so unbedingt dazu da, den gesamten RFC-Baum nachzubilden. Insofern ist die Information Updated / Obsoletes rein informativ, aber nicht Kernaufgabe der von der Vorlage gelieferten Information.

Es ist ein Angebot für eine lineare Abfolge genau eines Dokuments wie RFC 822, das durch genau einen Nachfolger ersetzt wird. Einen Baum (Graph), der sich teilt und irgendwann wieder vereinigt wird müssen wir nicht nachbauen.

In der beabsichtigten Logik bedürfte es Obsoletes2= Obsoletes3= Obsoletes4= Updated2= Updated3=.

Der derzeitige Workaround wäre statt Obsoletes= von vornherein, wenn man das für zitierenswert hält, Kommentar=Ersetzt RFC 2732, RFC 2396, RFC 1808.

LG --PerfektesChaos 15:16, 27. Nov. 2019 (CET)

Inwiefern „nach-magisch“? Gibt es Überlegungen, derlei Magie in Zukunft nicht mehr zu unterstützen? In MediaWiki generell (kann ich mir nur schwer vorstellen) oder nur in der deutschen Sprachausgabe hier?

Ich stehe auf dem Standpunkt, wenn ich schon Info vorsehe, dann sollte diese auch vollständig sein. Unvollständige Info ist für meine Begriffe gleichbedeutend mit falscher Info. Gleiches gilt für funktionale Durchgängigkeit.

Dass das mit der klassischen Vorlagensyntax nur statisch, d.h. sehr eingeschränkt, sehr mühsam und sehr unübersichtlich funktioniert, ist mir klar. Da steht aber „Diese Vorlage wurde ganz oder teilweise mit Hilfe der Programmiersprache Lua erstellt.“. Damit sollten Arrays, Listen oder meinetwegen auch nur String-Tokenizing doch ein Leichtes sein. Oder überschätze ich da die Möglichkeiten von Lua in Vorlagen? (Ich selbst habe noch keine damit programmiert, setzte aber anlässlich der Einführung große Hoffnungen hinein.)

LG --Geri, ✉  23:42, 27. Nov. 2019 (CET)

Ne da liegst du falsch, die Vorlage verwendet lediglich diese Funktion Wikipedia:Lua/Modul/TemplUtl#faculty die eine boolesche Abfrage vornimmt, da ist sonst rein gar nichts in Lua programmiert, denn ich kann gar kein Lua. Schau in den Quelltext {{#invoke:TemplUtl|faculty|{{{Errata|}}}}}. Einfach nur für Errata ja (true, vorhanden) oder nein (false, nicht vorhanden). Du überschätzt somit auch meine Fähigkeiten. Es sind schon weit mehr Informationen als die reine

• RFC 3986 liefert.
• T. Berners-Lee, R. Fielding, L. Masinter: RFC: 3986 – Uniform Resource Identifier (URI): Generic Syntax [Errata: RFC 3986]. Januar 2005, Abschnitt 3.4: Query. (löst RFC 2732 ab, aktualisiert durch RFC 6874, englisch).

Mehr mache ich da nicht.--Liebe Grüße, Lómelinde Diskussion 09:36, 28. Nov. 2019 (CET)

Was du dir vorstellen kannst, ist relativ egal.

• Die drei magischen Verlinkungen ISBN, PMID, RFC waren ein Betriebsunfall der allerersten Wiki-Programmierung gewesen.
• Es hätte Hunderte und Tausende weitere gegeben; DOI VIAF PubChem LCCN GND ISSN und was auch immer.
• Wenn jemand einen ganz normalen Text schreibt, dabei die Jahreszahl 1995 erwähnt und der Satzteil zuvor auf die Abkürzung RFC endet, dann führt das zu einer automatischen überraschenden Verlinkung, wobei der Text noch nicht einmal vom Internet handeln muss.
• Syntaktisch ist es katastrophal, dass ganz normale Buchstaben und Ziffern eine derartige Wirkung haben sollen. Eine http-URL hat ebenfalls einen magischen Effekt, aber hier ist es nachvollziehbar für Anwender, dass sich sowas automatisch verlinkt und gibt es auch in vielerlei anderen Internet-Textsystemen. Syntaktisch immerhin am Doppelpunkt mit vorangestellten eigentlich Kleinbuchstaben robuster abgrenzbar.
• Man hatte das sehr schnell erkannt und nach den ersten drei nie wieder sowas eingeführt. RFC gab es, weil die ersten Wiki-Programmierer täglich damit zu tun hatten; PMID war reiner Zufall, weil ein Beteiligter damit häufig hantierte und ISBN ergeben unter Gesamt-Zielstellung eines Wiki noch den meisten Sinn.
• Es wird eines Tages überhaupt keine magischen Links vom Typ PMID/RFC/ISBN mehr geben; die Frage ist nur der Zeitpunkt und die Reihenfolge. PMID und RFC werden sicher zuallererst deaktiviert; ISBN könnten sich übergangsweise noch etwas länger halten.
• [[rfc:1438]] und [[pmid:1]] sind seit langer Zeit die syntaktisch auswertbaren Nachfolger.
• Es gibt auch bereits eine Parallel-Implementierung außerhalb der MediaWiki-Kernfunktion, die zunächst bei allen WMF-Wikis aktiviert werden könnte; anschließend können die drei magischen Links aus dem Systemkern von MediaWiki eliminiert werden. Danach kann Wiki für Wiki die Funktionalität je nach Migrationsprozess abschalten; zunächst PMID und RFC. Globale Bots mögen unterstützen. Problem hätten dafür die Wikis in der Welt da draußen; die müssen das auch migrieren, haben aber wenig Systembetreuer und üblicherweise keine Bots. Aber sie können sich ggf. relativ einfach die neue Extension hinzukonfigurieren, oder bekämen sie sogar schon vorkonfiguriert mitgeliefert und müssten sie ggf. nur noch abschalten.
• Ach ja, ich spinne nicht: phab:T145604 phab:E27 – ich schreib sowas ja nicht aus Langeweile.

Die Aufgabe unserer Vorlagen und speziell dieser ist es, eine Zitation zu ermöglichen; dafür sind sowohl Updates wie Obsoleting überflüssig.

• Die Aufgabe dieser Vorlage ist es ausdrücklich nicht, die gesamte RFC-History durchnavigierbar abzubilden.
• Die fraglichen Zusatzinfos sind absolut nachrangig.

Fremder Leute Lua-Programmierungen pflegen können in diesem Projekt vielleicht ein, zwei oder drei Hanseln, die dann die Wartung sämtlicher Lua-Codes übernehmen müssten.

• Vorlagenprogrammierung können vielleicht 1.000 Aktive anpassen.
• Wir verwenden Lua deshalb ausschließlich dort, wo die Mittel der Vorlagenprogrammierung absolut nicht mehr ausreichen.
• Im vorliegenden Fall wird die Anzahl der in einer Generation gleichzeitig ersetzten oder ersetzenden RFC schon nicht gen Unendlichkeit streben, sondern auf drei, vier oder mal fünf begrenzt bleiben; deshalb gibt es keinen Bedarf für deinen Lua-Vorschlag.
• Bei Vorlage:min und Vorlage:max verhält es sich anders.

@Ló: Magst du dem sehr anspruchsvollen Herrn doch noch den Gefallen tun und ihm je eine 2, 3, 4 nachrüsten, damits a Ruah hat?

• Aber eigentlich kann er das ja sogar selbst hinzuprogrammieren; in klassischer Vorlagensyntax.

VG --PerfektesChaos 15:14, 28. Nov. 2019 (CET)

Wenn du so fragst, möchten möchte ich nicht, können könnte ich es vielleicht, denn dann wird er gleich noch weiter fragen und was ist mit „updates“ „obsoleted by“. Du weißt selbst, dass es quasi vier solche Funktionen gäbe.

• obsolates, obsolated
• updates, updated

und wohlmöglich noch ein endgültig aufgegeben und unwirksam. Ehrlich gesagt, nein ich möchte es nicht.

• L. Walleij: RFC: 3534 – The application/ogg Media Type. Mai 2003 (aktualisiert durch RFC 5334, Erstversion, englisch).
• I. Goncalves, S. Pfeiffer, C. Montgomery: RFC: 5334 – Ogg Media Types. September 2008 (löst RFC 3534 ab, aktualisiert durch RFC 7845, Zwischenversion, englisch).
• T. Terriberry, R. Lee, R. Giles: RFC: 7845 – Ogg Encapsulation for the Opus Audio Codec. April 2016 (aktualisiert durch RFC 8486, Nachfolgeversion, englisch).
• J. Skoglund, M. Graczyk: RFC: 8486 – Ambisonics in an Ogg Opus Container. Oktober 2018 (derzeit letzte Version, englisch).

Und auch aus dem Grunde nicht, weil sie gar nicht alle die selbe Bezeichnung haben, das ist wischiwaschi oder ein Mischmasch, wie ich ihn nicht mag. Die Zuordnung zu den Autoren passt dann auch nicht für alle Nummern. Nein, nein, nein ich mag nicht!!! --Liebe Grüße, Lómelinde Diskussion 15:51, 28. Nov. 2019 (CET)

Naja, für den Fall, dass genau ein Vorgänger ersetzt wurde bzw. es genau einen Nachfolger gab ist ja bereits alles in Butter, wie du gerade eben demonstriert hast.

Beanstandet wurde die hin und wieder auftretende Situation, dass mehrere Vorgänger durch nur einen einzigen Nachfolger (unsere Zitation) ersetzt wurden, oder umgekehrt dass unsere Zitation aufgeteilt wurde in mehrere Nachfolger.

Dazu bräuchte es neue optionale Parameter vom Typ number, die mit dem bisherigen Einzelstück zusammen eine Liste bilden: Updated2= Updated3= Updated4= Obsoletes2= Obsoletes3= Obsoletes4=

Unser Beanstander ist ja sehr technikaffin und weiß das sowieso alles ganz genau; das könnte er eigentlich selbst realisieren.

LG --PerfektesChaos 17:52, 28. Nov. 2019 (CET)

Soll er es doch machen ich mag, wie gesagt, nicht. Und das war ja deine Frage „magst du“. Du weißt, dass ich für dich fast alles tun würde. Die Vorlage gehört mir ja nicht. Ich hatte schon verstanden was du möchtest, dass ich tun sollte. Wenn es mehrere Nachfolger geben sollte dann kann man auch mehrere Vorlagen einbinden, mit einem Kommentar wo da denn der Unterschied wäre oder weshalb das gesplittet wurde. Ich kann mit diesen RFC’s eh nichts anfangen, das ist so gar nicht meine Welt. --Liebe Grüße, Lómelinde Diskussion 18:16, 28. Nov. 2019 (CET)

Internet Draft und sonstiges Referenzen

Wie können Internet Drafts der IETF und andere offizielle Dokumente und Veröffentlichungen (teilweise ohne Nummerkreis oder als Vorläufer eines RFCs) refereznziert werden? Die Vorlage Cite IETF ist hier inhaltlich vollständig, aber in :de nicht zu finden. Wo finde ich eine Entsprechung? Internetquelle und Cite web sind hier keine Alternativen, aufgrund fehlender Eigenschaften (Gremien, Arbeitsgruppen, Vorläufer, Nachfolger). RIMOLA (Diskussion) 10:59, 5. Jun. 2021 (CEST)

Die umseitige Vorlage ist speziell dafür vorgesehen, die langfristig nicht mehr unterstützten magischen Verlinkungen wie RFC 2324 zu ersetzen.

Per Definitionem gibt es damit immer eine reguläre Nummer.

Alle sonstigen Verlinkungen von irgendwas können direkt als Wikitext oder aber mittels Vorlage:Internetquelle eingebracht werden.

Warum das „keine Alternativen“ sein sollen, bleibt schleierhaft. Wenn da spezielle Angaben notwendig wären, können die hineingeschrieben werden. Wir haben 1,8 Millionen Einbindungen über Vorlage:Internetquelle im ANR und über 100 Millionen Einzelnachweise. Alle anderen haben es auch irgendwie hinbekommen.

Anders als die enWP unterhalten wir nicht für jeden Spezialfall und jede Website eine eigene Vorlage, sondern erst dann wenn es sich lohnen würde. Die letzten anderthalb Jahrzehnte hat es sich für uns offenkundig nicht gelohnt, und es gibt auch nur 100 IETF-Drafts. Da hatte von den Informatikern wohl noch niemand Lust verspürt, eine Zitation nach hiesigen Standards als Vorlage zu programmieren und zu dokumentieren und anschließend auch zu pflegen, zumal ja die meisten Erwähnungen schon seit einem Jahrzehnt drin sind und nur hin und wieder was Neues tröpfelt. Ein Monster mit 56 Parametern wie in der enWP werden wir hier sicher nicht haben wollen; das sind schon mehr als in der universellen Vorlage:Internetquelle. Unw während wir schon beinahe alle vielfach verwendeten Vorlagen mit Parametern über TemplateData dokumentiert haben, kommt die enWP damit nicht mehr hinterher, as see.

VG --PerfektesChaos 03:33, 6. Jun. 2021 (CEST)