RFC-editor, thank you for preparing this RFC-to-be.
We’ll first reply to the more specific ones of your questions below. We will respond to more general questions (that require us to scan the document) in the next round (marked here with TO CHECK in questions 6, 20, 21, 22, 23). Please note that we are also preparing a -25, with two typo/C&P fixes and one more technical omission fixed (PR #187 to #189 in https://github.com/ietf-wg-asdf/SDF/pulls). We previously prepared a -24 with PR #186 in it (technical omissions), which you already picked up. You probably need AD approval for all these. Grüße, Carsten On 2025-10-07, at 07:03, [email protected] wrote: > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> IoT Device Model Interaction Model Affordance Property Action Event > 2) <!-- [rfced] We are having trouble understanding how the text after the > comma relates to the earlier part of the sentence. Does this mean Group in > nested definitions also represents the SDF document? Please clarify. > > Original (full definition included for context): > Group: An entry in the main JSON map that represents the SDF > document, and in certain nested definitions. A group has a Class > Name Keyword as its key and a map of named definition entries > (Definition Group) as a value. > > Perhaps: > Group: An entry in the main JSON map and certain nested definitions > that represent the SDF document. > --> The “that represents the SDF document” is a qualification of “JSON map”, so “that represent the SDF document” can’t move this way. It also turns out that we didn’t use the term “main” with JSON maps anywhere else, so we should replace this with “top-level JSON map” (in the way we use top-level in 3.4). Maybe: > Group: An entry in the top-level JSON map that represents the SDF > document. Groups also can be used in certain nested definitions. > 3) <!-- [rfced] Some author comments are present in the XML. Please confirm > that no updates related to these comments are outstanding. Note that the > comments will be deleted prior to publication. > --> > Besides comments marked [rfced] and some of your comments on references, I see tool-generated comments in one SVG. These indeed can be deleted. > 4) <!-- [rfced] The SVG figure contains duplicate ids, which generates > invalid HTML. We ran a utility that is supposed to create unique ids within > the SVG on a copy of the file, but it didn't seem to work. xml2rfc yields > the following warning - please review and let us know if a correction is > possible. > > rfc9880.xml(480): Warning: Duplicate attribute id="link_sdfAction_sdfData" > found after including svg from inline:b'<svg xmlns:xlink="http://www.w3' > .... This can cause problems with some browsers. > --> That is an interesting bug of the plantuml tool, apparently triggered by the fact that there are two arrows from sdfAction to sdfData. I’m not sure why kramdown-rfc-clean-svg-ids doesn’t catch (and fix) this; I would say this is a bug in that tool. But the IDs are not actually used in any IDREF, so we can work around this by arbitrarily changing the IDs in the two lines <g id="link_sdfAction_sdfData"> e.g., into <g id="link_sdfAction_sdfData1"> <g id="link_sdfAction_sdfData2"> > 5) <!-- [rfced] Figure 2: The SVG includes additional information that is > not present in the text. Is this as expected? For example, we see 0+, 1, > and (c) in the SVG but not in the text artwork. In addition, sdfEvent and > sdfAction appear in a different order. Please review. > --> We originally had completely given up on providing a plaintext form of the illustration. The plaintext illustration that now is in there is somewhat rudimentary. As you notice, it doesn’t have the occurrence labels (0+, 1), and it doesn’t mark the boxes as compositions which looks almost like a © symbol in the generated SVG. We do warn that this is a limited rendition, so we think we are good. > 6) <!-- [rfced] Please review whether any of the notes in this document > should be in the <aside> element. It is defined as "a container for > content that is semantically less important or tangential to the > content that surrounds it" > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > --> [TO CHECK] > 7) <!-- [rfced] May we rephrase "itself" to "which is" for improved > readability? > > Original: > From the outside of a specification, Given Names are usually used as > part of a hierarchical name that looks like a JSON pointer [RFC6901], > itself generally rooted in (used as the fragment identifier in) an > outer namespace that looks like an https:// URL (see Section 4). > > Perhaps: > From the outside of a specification, Given Names are usually used as > part of a hierarchical name that looks like a JSON pointer [RFC6901], > which is generally rooted in (used as the fragment identifier in) an > outer namespace that looks like an https:// URL (see Section 4). > --> Oh, we need to be more careful about the syntactic reference. It is the JSON pointer that is rooted/used as, not the entire hierarchical name. Neither version really makes that clear. So this indeed should be rephrased; our try: Maybe: From the outside of a specification, Given Names are usually used as part of a hierarchical name that looks like a JSON pointer [RFC6901]. These hierarchical names are generally rooted in (used as the fragment identifier in) an outer namespace that looks like an https:// URL (see Section 4). > 8) <!-- [rfced] May we rephrase the text below as follows to improve > readability and specify "it" in the second sentence? > > Original: > The keyword (map key) that defines an information block is "info". > Its value is a JSON map in turn, with a set of entries that represent > qualities that apply to the included definition. > > Perhaps: > The keyword (map key) that defines an information block as "info". This should stay “is” — not a sentence otherwise. (This is a statement about the keyword, giving its name as “info”.) > In turn, the keyword's value is a JSON map with a set of entries that > represent > qualities that apply to the included definition. > --> We could also make use of the word “nested”: > The keyword's value is nested a JSON map with a set of entries that represent > qualities that apply to the included definition. In any case, we need to change OLD: included definition NEW: included definitions … to mirror the first paragraph of 3.1. > 9) <!-- [rfced] We suggest rephrasing the following sentence (i.e., > adjusting the placement of "using"). Does the following suggestion retain > the sentence's original meaning? > > Original: > This specification does not > give a strict definition for the format of the version string but > each using system or organization should define internal structure > and semantics to the level needed for their use. > > Perhaps: > This specification does not give a strict definition for the format > of the version string, but each system or organization using the version > string should define internal structure and semantics to the level needed for > their use. > --> Much better. Thank you. > 10) <!-- [rfced] Should "JSON pointer" be rephrased as "a JSON pointer" or > "JSON pointers" to describe Figure 4? > > Original: > The > example also shows the use of JSON pointer with "sdfRef" to use a > pre-existing definition for the sdfProperty "currentTemperature" and > for the sdfOutputData produced by the sdfEvent > "overTemperatureEvent". > > > Perhaps: > The > example also shows the use of a JSON pointer with "sdfRef" to use a > pre-existing definition for the sdfProperty "currentTemperature" and > for the sdfOutputData produced by the sdfEvent "overTemperatureEvent". > > Or: > The > example also shows the use of JSON pointers with "sdfRef" to use a > pre-existing definition for the sdfProperty "currentTemperature" and > for the sdfOutputData produced by the sdfEvent "overTemperatureEvent". > --> > The latter one, as there are two JSON pointer examples in sdfRefs. ("JSON pointer" can stand for the uncountable concept, but here there truly are two JSON pointers of this kind [and a few more other ones as well].) > 11) <!-- [rfced] FYI - In the XML, we have removed the links from "SenML > Units" and "Secondary Units" since those links do not point to the correct > section (and the correct section pointers follow shortly > thereafter). Please let us know any objections. I’m not happy with not having those fragment identifiers as links. I understand that IANA wants to keep the ability to change their format, but that has been outstanding for a long time now. The worst that can happen is that the fragment identifier part of the link does not work and the link points to the file as a whole. > Original XML: > <t>The unit name <bcp14>SHOULD</bcp14> be as > > per the <xref section="SenML Units" relative="#senml-units" > sectionFormat="bare" > target="RFC8428"/> registry > > or the <xref section="Secondary Units" relative="#secondary-units" > sectionFormat="bare" > target="RFC8798"/> registry in <xref target="IANA.senml"/> > > as specified by > > Sections <xref target="RFC8428" section="4.5.1" sectionFormat="bare"/> and > <xref > target="RFC8428" section="12.1" sectionFormat="bare"/> of <xref > target="RFC8428"/> and > <xref section="3" sectionFormat="of" target="RFC8798"/>, respectively. </t> > --> > > > 12) <!-- [rfced] The IANA registry includes "(note 1)" as part of the > description for unix-time, but there is no note included in the registry. > Should the notes be included in the registry Yes, please. > or perhaps "(note 1)" should > be removed from the description? > > Original (text): > | unix-time | A point in | number | POSIX time | Section | > | | civil time | | | 3.4.2 of | > | | (note 1) | | | RFC 8949 | > | | | | | [STD94] | > > See the IANA registry: > https://www.iana.org/assignments/sdf/sdf.xhtml#sdftype-values > --> > > > 13) <!-- [rfced] IANA provided the following notes to the RFC Production > Center. We believe the document has been updated accordingly. Please > review and let us know if any updates are needed. > > NOTE 1: The authors have notified us that "4.5.1" (Names) needs to be > changed to "4.5.2" (Units) both in the "Repository" field in Section 7.3 > and in Note 1 to Table 4 in Section 4.7. That is correct, so s/4.5.1/4.5.2/ in both places. > NOTE 2: With author permission, we've prepended "SDF" to the three new > registry names that didn't already refer to SDF. > --> Thank you! > 14) <!-- [rfced] We have updated this text to remove the use of relative > references. Please review. > > Original: > Repository: combining the symbol values from the SenML Units > registry and the Secondary Units registry in [IANA.senml] as > specified by Sections 4.5.1 and 12.1 of [RFC8428] and Section 3 of > [RFC8798], respectively (which by the registration policy are > guaranteed to be non-overlapping). > > Current: > Repository: Combining the symbol values from the "SenML Units" > registry and the "Secondary Units" registry in the "Sensor > Measurement Lists (SenML)" registry group [IANA.senml] as > specified by Sections 4.5.2 and 12.1 of [RFC8428] and Section 3 of > [RFC8798], respectively (which, by the registration policy, are > guaranteed to be non-overlapping). > --> > (I can’t see the change in the plaintext here…) Please see my comment about relative references into IANA registries above in question 11. > 15) <!-- [rfced] Please review the text below. We note that "sub-delims" is > not mentioned in Section 2.3 of RFC 3986 [STD66]. The term is defined in > Section 2.2 of RFC 3986 [STD66]. Should Section 2.3 be updated to Section > 2.2? > > Original: > Index value: Percent-encoding (Section 2.1 of RFC 3986 [STD66]) is > required of any characters in unit names except for the set > "unreserved" (Section 2.3 of RFC 3986 [STD66]), the set "sub- > delims" (Section 2.3 of RFC 3986 [STD66]), ":" or "@" (i.e., the > result must match the ABNF rule "pchar" in Section 3.3 of RFC 3986 > [STD66]). > --> Good catch; sub-delims is 2.2, unreserved is 2.3. So: OLD: delims" (Section 2.3 of RFC 3986 [STD66]), ":" or "@" (i.e., the NEW: delims" (Section 2.2 of RFC 3986 [STD66]), ":" or "@" (i.e., the _______________________^ > 16) <!-- [rfced] What is "these" referring to in the sentence below? > > Current: > In applications that dynamically acquire models and obtain modules > from module references in these, the security considerations of > dereferenceable identifiers apply (see [DEREFERENCEABLE-ID-PATTERN] > for a more extensive discussion of dereferenceable identifiers). > > Perhaps: > In applications that dynamically acquire models and obtain modules > from module references in these applications, the security > considerations of dereferenceable identifiers apply (see > [DEREF-ID-PATTERN] for a more extensive discussion of > dereferenceable identifiers). > --> “these” is about the models dynamically acquired. OLD: from module references in these, the security considerations of NEW: from module references in these models, the security considerations of (The alliteration of module and model is unfortunate, but apparently unavoidable here.) > 17) <!-- [rfced] References > > a) Please review the following reference. The original URL for this > reference - > http://www.openmobilealliance.org/wp/omna/lwm2m/lwm2mregistry.html - > redirects to the following URL: > https://www.openmobilealliance.org/specifications with the title "OMA > Specifications". > > We could not find a page with the original title for this reference "OMA > LightweightM2M (LwM2M) Object and Resource Registry". We did find the > following page: https://www.openmobilealliance.org/specifications/registries, > which contains separate links to the LwM2M Objects and > Resources registries. > > Would you like to update this reference to point to this new URL? > > Current: > [OMA] Open Mobile Alliance, "OMA LightweightM2M (LwM2M) Object > and Resource Registry", > <http://www.openmobilealliance.org/wp/omna/lwm2m/ > lwm2mregistry.html>. Right, so the URL and the title would need to be updated. The actual HTML page title is awkward, though. Title: openmobilealliance.org/specifications/registries/objects/ Maybe we can use the <h1> title instead of the document.title (which I don’t find in the page source, by the way): NEW: Title: LwM2M OBJECTS Link: https://www.openmobilealliance.org/specifications/registries/objects This link is slightly more specific than what we referenced before, but fits the site of the citation (which is about objects, not about resources) even better. (With my browser, the page briefly indicates that it is embarrassed about itself and then switches back to what we want here; this may need some additional debugging.) > b) The information for this reference appears to be from the 2020 version > of ECMA Standard ECMA-262. However, the URL provided points to the 2024 > edition. > > We've updated this reference to use the information from the URL - that is, > the 2024 edition. Please let us know if you have any objections. > > Current: > [ECMA-262] Ecma International, "ECMAScript 2024 Language > Specification", 15th Edition, ECMA Standard ECMA-262, June > 2024, <https://www.ecma-international.org/wp- > content/uploads/ECMA-262.pdf>. > --> By now, that would be title: ECMA-262, 16th edition, June 2025 link: https://ecma-international.org/wp-content/uploads/ECMA-262_16th_edition_june_2025.pdf Of course, the intention is not to point just to this specific revision. I don’t think we have a general guideline how to deal with documents that are on a regular update schedule, so simply going to the 2025 revision might be the right thing to do. (This is based on the belief that the new functionality in 16th edition relative to 11th edition does not extend the pattern language resulting from applying the suggested limitations in Appendix C.2 to the referenced edition. Updating these links does need some care…) > 18) <!-- [rfced] Should "their complements" be placed on a separate bullet > to follow the original pattern of this list? > > Original: > * characters; > * character classes in square brackets, including ranges; their > complements; > * simple quantifiers *, +, ?, and range quantifiers {n}, {n,m}, and > {n,}; > * grouping parentheses; > * the choice operator |; > * and anchors (beginning-of-input ^ and end-of-input $). > > Perhaps: > * characters; > * character classes in square brackets, including ranges; > * their complements; > * simple quantifiers *, +, ?, and range quantifiers {n}, {n,m}, and > {n,}; > * grouping parentheses; > * the choice operator |; > * and anchors (beginning-of-input ^ and end-of-input $). > --> Complements are specific to character classes (the complement of [abc] would be [^abc]), so we think this is easier to understand as part of the same bullet item. > 19) <!-- [rfced] Does "earlier drafts" refer to earlier drafts of the I-D > that became this RFC or earlier versions of SDF (defined elsewhere)? Perhaps > this can be clarified? > > Current: > Appendix E. Some Changes From Earlier Drafts > --> The first (real) paragraph of Appendix E is actually intended to clarify this. To answer the question: All the published draft specs have been Internet-Drafts, see timeline on https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf/ “Earlier drafts” of course is a bit confusing as the RFC-to-be no longer is a draft. Maybe “from drafts of this specification”? > 20) <!-- [rfced] Please review each artwork element and let us know if any > should be marked as sourcecode (or another element) instead. > > We updated Figure 5 from artwork to sourcecode. Please confirm that this is > correct. When does a snippet (like the one about warning/danger in 2.3.2, which is marked as artwork) become sourcecode? Figure 5 is not really parsable per se, it needs to be integrated into context to *really* be sourcecode. Despite this, marking it as JSON sourcecode probably is OK (even if kramdown-rfc would complain that it isn’t really JSON, because it is a snippet, or actually two of them in one figure). > In addition, please consider whether the "type" attribute of any sourcecode > element should be set and/or has been set correctly. [TO CHECK] > The current list of preferred values for "type" is available at > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. > If the current list does not contain an applicable type, feel free to > suggest additions for consideration. Note that it is also acceptable > to leave the "type" attribute not set. We haven’t really discussed so far whether there should be a sourcecode type specifically for SDF. By default, application/sdf+json is one (usually leaving out application/, so just “sdf+json”). We do have precedent for using structured syntax suffixes in yang-instance-data+json, so nothing appears to speak against use that. (There are 25 instances where this needs to be checked.) > --> > 21) <!-- [rfced] We note that these terms appear both with and without <tt> > tags. Please review each instance of the terms below and ensure that they > appear in the document as desired. If these terms should be formatted > consistently or follow a specific pattern, please let us know. [TO CHECK] Generally, when the sourcecode construct is meant, we use the typewriter font; when the concept is meant (“an array of string values”…), we don’t, and we then use the English capitalization (“Boolean”). > <tt>absolute-URI</tt> > <tt>array</tt> > <tt>boolean</tt> > <tt>curie</tt> > <tt>date-time</tt> (also appears in quotes) > <tt>defaultNamespace</tt> > <tt>description</tt> > <tt>enum</tt> > <tt>false</tt> > <tt>features</tt> (also appears in quotes) > <tt>format</tt> > <tt>info</tt> > <tt>integer</tt> > <tt>items</tt> > <tt>json-schema.org</tt> > <tt>label</tt> > <tt>length</tt> > <tt>named-sdq</tt> > <tt>namespace</tt> > <tt>null</tt> > <tt>number</tt> > <tt>object</tt> (also appears in quotes) > <tt>pattern</tt> (also appears in quotes) > <tt>properties</tt> (also appears in quotes) > <tt>referenceable-name</tt> (also appears in quotes) > <tt>required</tt> > <tt>sdfAction</tt> > <tt>sdfChoice</tt> > <tt>sdfData</tt> > <tt>sdfEvent</tt> > <tt>sdfObject</tt> > <tt>sdfOutputData</tt> > <tt>sdfProperty</tt> > <tt>sdfRef</tt> > <tt>sdfRequired</tt> (also appears in quotes) > <tt>sdfThing</tt> > <tt>sdf</tt> > <tt>sdfType</tt> > <tt>string</tt> > <tt>toggle</tt> (also appears in quotes) > <tt>true</tt> > <tt>type</tt> > <tt>unit(s)</tt> > <tt>value</tt> > --> > > > 22) <!-- [rfced] Please review the following terms and let us know if/how > we should update for consistency. > > a) Capitalization > affordance vs. Affordance We generally capitalize new terms in the definition of terms (section 1.2) but tried to avoid drowning in capitalized words all over the text. Terms introduced in this section are capitalized when used in this section. To maintain readability, capitalization is only used when needed where they are used in the body of this document. It seems the capitalization of Affordance is consistent with this. > boolean vs. Boolean Concept (Boolean, after George Boole) vs. the name of the type in the SDF document (boolean, in that spelling). > CURIE vs. curie Generally, CURIE is the concept (and this needs to be fixed in a few places). Lowercase “curie” is the name of the production in W3C.NOTE-curie-20101216 > JSON pointer vs. JSON Pointer This is indeed inconsistent. RFC 6901 uses JSON Pointer consistently, but we don’t have to follow their style. But since JSON already is all-caps, maybe it doesn’t hurt to do so. Continue here later… [TO CHECK] > Properties vs. properties > quality names vs. Quality Names > SDF model vs. SDF Model > > b) Spacing > data qualities vs. dataqualities > data quality vs. data quality ? > c) Other > base SDF vs. SDF base > --> > > > 23) <!-- [rfced] FYI - We have added expansions for abbreviations upon > first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > each expansion in the document carefully to ensure correctness. > --> We’ll get to this in the diff reading phase. [TO CHECK] > 24) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. --> We wrote the text with this style objective in mind and are not aware of any further changes needed. > Thank you. Thank you! > Madison Church and Sandy Ginoza > RFC Production Center > > > > > On Oct 6, 2025, at 9:57 PM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/10/06 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * [email protected], which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > [email protected] will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9880.xml > https://www.rfc-editor.org/authors/rfc9880.html > https://www.rfc-editor.org/authors/rfc9880.pdf > https://www.rfc-editor.org/authors/rfc9880.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9880-diff.html > https://www.rfc-editor.org/authors/rfc9880-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9880-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9880 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC 9880 (draft-ietf-asdf-sdf-24) > > Title : Semantic Definition Format (SDF) for Data and Interactions > of Things > Author(s) : M. Koster, Ed., C. Bormann, Ed., A. Keränen > WG Chair(s) : Michael Richardson, Lorenzo Corneo > > Area Director(s) : Andy Newton, Orie Steele > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
