DDDS (Dynamic Delegation Discovery System) defines a mechanism for using a DNS-like as the database for arbitrary identifier schemes.
The DDDS is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached.
Annotats des RFC/Annoted RFCs
- ANN-RFC8126 - ANN-BRTZ-8126 : IANA Considerations Section in RFCs
- ANN-RFC8141 - ANN-BRTZ-8141 : Dynamic Delegation Discovery System (DDDS) Uniform Resource Names (URNs)
- ANN-RFC3401 - ANN-BRTZ-3401 : Dynamic Delegation Discovery System (DDDS) Part One: The Algorithm
- ANN-RFC3402 - ANN-BRTZ-3402 : Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
- ANN-RFC3403 - ANN-BRTZ-3403 : Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
- ANN-RFC3404 - ANN-BRTZ-3404 : Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)
- ANN-RFC3405 - ANN-BRTZ-3405 : Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures
- ANN-RFC3958 - ANN-BRTZ-3958 : Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
- ANN-RFC4095 - ANN-BRTZ-4095 : Attaching Meaning to Solicitation Class Keywords
- ANN-RFC4848 - ANN-BRTZ-4848 : Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)
- ANN-RFC5526 - ANN-BRTZ-5526 : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM
- ANN-RFC6116 - ANN-BRTZ-6116 : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
- ANN-RFC3238 - ANN-BRTZ-3238 : IAB Architectural and Policy Considerations for Open Pluggable Edge Services
- ANN-RFC3752 - ANN-BRTZ-3752 : Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios
- ANN-RFC3835 - ANN-BRTZ-3835 : An Architecture for Open Pluggable Edge Services (OPES)
- ANN-RFC3836 - ANN-BRTZ-3836 : Requirements for Open Pluggable Edge Services (OPES) Callout Protocols
- ANN-RFC3837 - ANN-BRTZ-3837 : Security Threats and Risks for Open Pluggable Edge Services (OPES)
- ANN-RFC3838 - ANN-BRTZ-3838 : Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)
- ANN-RFC3897 - ANN-BRTZ-3897 : Open Pluggable Edge Services (OPES) Entities and End Points Communication
- ANN-RFC3914 - ANN-BRTZ-3917 : Open Pluggable Edge Services (OPES) Treatment of IAB Considerations
- ANN-RFC4037 - ANN-BRTZ-4037 : Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core
- ANN-RFC4236 - ANN-BRTZ-4236 : HTTP Adaptation with Open Pluggable Edge Services (OPES)
- ANN-RFC4496 - ANN-BRTZ-4496 : Open Pluggable Edge Services (OPES) SMTP Use Cases
- ANN-RFC4902 - ANN-BRTZ-4902 : Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP
Identification and description of language varieties
- ISO 639-1:2002, Codes for the representation of names of languages Part 1: Alpha-2 code
- ISO 639-2:1998, Codes for the representation of names of languages Part 2: Alpha-3 code
- ISO 639-3:2007, Codes for the representation of names of languages Part 3: Alpha-3 code for comprehensive coverage of languages
- ISO 639-4:2010 Codes for the representation of names of languages -- Part 4: General principles of coding of the representation of names of languages and related entities, and application guidelines
- ISO 639-5:2008, Codes for the representation of names of languages Part 5: Alpha-3 code for language families and groups
- ISO 3166-1:2006, Codes for the representation of names of countries and their subdivisions Part 1: Country codes
- ISO 3166-2:2007, Codes for the representation of names of countries and their subdivisions Part 2: Country subdivision code
- ISO 3166-3:1999, Codes for the representation of names of countries and their subdivisions Part 3: Code for formerly used names of countries
- ITU-T X.1081:2004, The telebiometric multimodal model A framework for the specification of security and safety aspects of telebiometrics
- IEC 80000-14:2008, Quantities and units Part 14: Telebiometrics related to human physiology
- ISO/IEC 11179-2:2005, Information technology Metadata registries (MDR) Part 2: Classification
- ISO/IEC 11179-3:2003, Information technology Metadata registries (MDR) Part 3: Registry metamodel and basic attributes
- ISO/IEC 11179-4:2004, Information technology Metadata registries (MDR) Part 4: Formulation of data definitions
- ISO/IEC 11179-5:2005, Information technology Metadata registries (MDR) Part 5: Naming and identification principles
- ISO/IEC 11179-6:2005, Information technology Metadata registries (MDR) Part 6: Registration
- ISO 12620:2009, Terminology and other language and content resources Specification of data categories and management of a Data Category Registry for language resource
Appel JFCM REF6852
De 1986 à 2016 l'innovation architecturale de l'internet a été bloquée par une stratégie de standardisation, d'intérêt américain, dite du "status quo". Celle-ci, devenue industriellement obsolète, a été remplacée une approche normative commercialement biaisée (aux termes de la RFC 1869), soutenue par une "Transition" institutionelle majeure et fait un consensus politique vérifié par le déni d'une procédure d'appel technique :
From 1986 to 2016, the architectural innovation of the Internet was blocked by a strategy of standardization of American interest, known as the "status quo". The latter, which has become industrially obsolete, has been replaced by a commercially skewed (cf. RFC 1869) normative approach , supported by a major institutional "Transition" and a political consensus verified by the denial of a technical appeal procedure:
- "iana.arpa 404" : 2015-03-11 appeal to the IESG.
L'innovation est considérée comme progressive ou disruptive. Elle peut également être rétrospective. Dans ce dernier cas l'on considère de nouveau une ancienne étape d'innovation avec toute l'expérience acquise depuis cette étape, et l'on met à jour l'innovation considérée depuis son tout début, la libérant de toutes les rustines et blocages ajoutés.
Innovation is considered as either incremental or disruptive. It also can be retrospective. In this later case one considers back a former innovation step with all the experience acquired from this step, and one updates the considered innovation from its very begining, freeing it from all the added patches and blockages.
Le concept fondamental du réseau consistait à mailler des Tymnet Engines / IMP grâce à des lignes dédiées. Reprenons l'innovation du réseau à partir de là. Avec tout ce que depuis nous avons appris et oublié.
The fundamental networking concept was to mesh Tymnet Engines/IMP through dedicated lines. Let us reconsider network innovation from then on. With all what we since learned and forgot.
L'histoire de l'architecture du réseau a commencé à la fin des années 60, stabilisée à la fin des années 70, a été gelée à la fin des années 80; Sa gouvernance technique s'est stabilisée à la fin des années 90, sa gouvernance politique à la fin des années 10. Nous sommes maintenant au temps d'une innovation rétrospective sur un demi-siècle.
The network architectural history started in the late 60s, stabilized in the late 70s, was frozen in the late 80s ; its technical governance stablized in the late 90s, its political governance in the late 10s. We are now at the half-century retrospective innovation time.
Un jour, Larry (Lawrence) Robert a traversé le lobby du CCITT (ITU/T) à Genève, et salué de la main un groupe d'ingénieurs des PTT européennes et Bob Trehin, responsable de TNSC (Tymnet Network Systems Consulting); Peter Lunquist de Televerket (PTT suédoises) dit alors aux autres: "il nous occupe avec sa série X ! mais nous l'utilisons tous au-dessus du protocole Tymnet".
Once, Larry (Lawrence) Robert crossed the CCITT (ITU/T) lobby in Geneva, waving "hello !" to a group of European PTTs' engineers and Bob Trehin, head of TNSC (Tymnet Network Systems Consulting) ; Peter Lunquist from Televerket (Swedish PTT) then told the others: "he keeps us busy with his X series! but all of us use it over the Tymnet protocol!".
L'exploration du modèle OSEX des Services Etendus de Tymnet et la seconde motivation du projet internet ont été bloqués à partir de 1986 par la stratégie du "status quo" du datagramme passif. Le datagramme délinéé actif (intelligramme) est la réponse maintenant rendue possible, en particulier dans le cadre de la post-Transition et de la communauté globale RFC 6852 XLIBRE.
The Tymnet/Extended Services OSEX model exploration and the second motivation of the Internet project were blocked from 1986 on by the "status quo" strategy of the passive datagram. The active delineated datagram (intelligram) is the answer now made possible, particularly in the post-Transition and XLIBRE RFC 6852 global community context.
La délinéation des intelligrammes réclame un service d'accompagnement sémantique (SAS) capable de supporter les zones sémantiques des VGNs (réseaux virtuels glocaux) dans le contexte du "presentation layer uniform space" (PLUS) de l'intersem.
Delineating intelligrams requires a semantic accompaniment service (SAS) capable of supporting the semantic zones of VGNs ("virtual glocal networks") in the context of the intersem presentation layer uniform space (PLUS).
While this project has potential to develop eventually into an international standard, at this stage, it should be developed as a Technical Report, or at most, a Technical Specification, an not an International Standard. The framework requires more development, and a more clearly-identified adopting customer base before it can actually succeed as an International Standard. A longer-term plan can be maintained for possible development beyond a Technical Report.
NWIP: Purpose and justification
It would help to see more information about anticipated consumers of this project, preferably with indications of some level of commitment to adopting it.
The NWIP cites speech technology as one sector for which the proposed metadata framework will be an essential prerequisite to sustainability and interoperability of resources. Yet very little information is provided indicating how the proposed standard (or technical specification) would relate to any metadata frameworks that are in actual usage in the speech technology sector.
The only reference of this nature is to CLARIN Metadata Set for Speech Resources, in clause 5.1, but no additional details and no other references are cited. Nor is there indication of active support from any organizations directly connected with the speech technology industry. The only liaisons suggested are within TC37 itself, whereas, with an emphasis given to speech technologies, one might expect liaison relationships with some external agencies dealing with speech technologies, such as the W3C (with relevant specifications including VoiceXML and Pronunciation Lexicon Specification); and at a minimum, with JTC1/SC35, which has a scope that encompasses speech and assistive technologies.
The NWIP should, preferably, provide indication of support for or partnership in the development of a standard or specification from outside TC3.
Clause 3.2, 3.3, 4.2
The NWIP and accompanying WD provides a model for describing language variations in terms of eight dimensions of variation, with additional sub-dimensions. It is not made clear, however, to what extent this model has been researched and exercised in actual usage in order to evaluate its sufficiency and fit as a best-practice model for the intended purposes. If such research has been conducted or if there has been prior usage, references to such work should be included in a NWIP. If not, that would underscore that this proposal, however promising, is premature for consideration as an international standard.
ISO 2282-29:1999 is used as a source for the definition of a term. Evidently, that standard has been withdrawn.
There is discussion of text conversion ---“transcription” and “transliteration”. Consideration should be given to the “T” extension of BCP 47 to assess possible relevance in development of this specification.
There is discussion of speakers imitating speech in a different language variety than their own. Consideration should be given to the “T” extension of BCP 47 to assess possible relevance in development of this specification.
The sub-clauses under clause 4.2 are numbered as 4.3.x.
The working draft cites the need for a registration mechanism but view that as a later development. As noted, such a registry is an essential pre-requisite for any mechanism that can provide interoperability of metadata. Therefore, a minimal requirement to succeed as an international standard should be the establishment of such a registry or at least a specification of requirements for any applications that might create such a registry. If the project is not yet sufficiently mature for this, then we consider that a good indication that the project is not yet sufficiently mature to comprise an international standard.
Under any circumstances, we feel it is essential for a project of this nature to be developed with deep awareness and understanding of IETF BCP 47. The working draft cites the IETF BCP 47 specification and its provision for defining extensions, suggesting the possibility of a BCP 47 extension based on the proposed framework.
Such an extension would need to specify or make normative reference to a registry of language-variation elements. Specification of such an extension to BCP 47 might be a very useful way to establish not only a registry of semantic language-variation attribute categories, but also a formalized metadata protocol for interchange of language variation descriptions / identifiers. This may be a useful direction for development beyond a Technical Report that TC37/SC2 may want to consider.