Or, would it be best to remove the non-mailto contacts from the examples, and add a note indicating that "mailto" is the only contact URI scheme currently supported by the ACME standards?
Sincerely, Logan Widick On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick <[email protected]> wrote: > This is related to my previous "Allowable mailto contacts" thread earlier > this month. However, this is about a different type of contact, so I > decided to start a new thread. > > Although ACME servers don't have to include support for "tel" (RFC 3966) > contacts, "tel" contacts appear in multiple examples in the ACME > specification. Thus, some may try to include "tel" contact support in their > ACME server implementations. > > Although the example "tel" contacts in the ACME specification seem to > indicate a simple, narrow subset (the "global-number" with zero "par" > instances), the "tel" specification has many more possible productions. For > example, both "global-number" and "local-number" may have "par" instances > (like ";name1=value1;name2=value2") after the phone numbers. > > Assuming I understand the "local-number" specification correctly, a > "local-number" could potentially contain a pound sign ("#") for reasons > related to DTMF. If I understand the current and past URI specifications > correctly, this could be problematic. Specifically, a URI parser may put > the parts of the "local-number" after a "#" in the fragment. > > If someone wanted to implement "tel" contact support for an ACME server, > what subset of "tel" would be required? Would both "global-number" and > "local-number" instances be allowed? What restrictions would apply to > "global-number" and "local-number" instances? Which types of "par" > instances would be allowed? Extension? ISDN-subaddress? Others? > > On a more general note, I think that as ACME becomes more widely used, the > subject of what subsets of what contact URI schemes would be allowed under > ACME (as opposed to what schemes are supported by a specific ACME server, > which was a separate issue already discussed in March on the mailing list > under "Allowing clients to understand the account creation functionality > supported by a server") may come up more often. Would it be a good idea to > request the creation of an "ACME Contact Schemes Registry" like in the > ASCII art figures below? > > > > > +--------+-----------+-----------+-------------------------- > -------------------+ > | Scheme | Status | Reference | ACME Restrictions > | > +--------+-----------+-----------+-------------------------- > -------------------+ > | mailto | Mandatory | RFC 6068 | Exactly one "addr-spec" in the "to" > portion | > | | | | No "hfields" are allowed > | > | | | | [Source: "Allowable mailto contacts" > thread]| > +--------+-----------+-----------+-------------------------- > -------------------+ > | tel | Optional | RFC 3966 | [insert restrictions picked in this > thread] | > +--------+-----------+-----------+-------------------------- > -------------------+ > > Figure 1: A possible "ACME Contact Schemes Registry" table. In this > version, the ACME restrictions on the original contact scheme > specifications are stated in the table, and the original contact scheme > specification is listed as the "Reference". These relationships are > depicted graphically in Figure 2 (below). > > > > > +-----------------------+ +--------------------+ > | RFC 6068 (mailto RFC) | | RFC 3966 (tel RFC) | > +-----------------------+ +--------------------+ > > Figure 2: RFC relationships for Figure 1 > > > > > +--------+-----------+---------------------------+ > | Scheme | Status | Reference | > +--------+-----------+---------------------------+ > | mailto | Mandatory | RFC XXXX | > | | | (ACME RFC) | > | | | | > +--------+-----------+---------------------------+ > | tel | Optional | RFC YYYY | > | | | (Some RFC after RFC XXXX) | > +--------+-----------+---------------------------+ > > Figure 3: Another possible "ACME Contact Schemes Registry" table. In this > version, the "Reference" RFCs discuss the ACME-specific restrictions for > the contact schemes, and refer to the original specifications for the > contact schemes. These relationships are depicted graphically in Figure 4 > (below). > > > > > +-----------------------------+ > | ACME restrictions on mailto | > +----------+------------------+ > ^ > | > | Contains > | > +----------+----------+ +--------------+ > | RFC XXXX (ACME RFC) | References | RFC 6068 | > + +----------------> + (mailto RFC) | > | | | | > +----------+----------+ +--------------+ > ^ > | > | References > | > +----------+-------------------+ +-----------+ > | RFC YYYY | References | RFC 3966 | > + (An RFC after RFC XXXX) +----------------> + (tel RFC) | > | | | | > +----------+-------------------+ +-----------+ > ^ > | > | Contained in > | > +----------+------------------+ > | ACME Restrictions on tel | > +-----------------------------+ > > Figure 4: RFC relationships for Figure 3 version of "ACME Contact Schemes > Registry" >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
