I would be supportive of removing non-mailto contact examples. I don't think it's accurate to say that "mailto" is the only contact scheme currently supported by the ACME standard. That isn't the case for the spec as-written today - it is the only mandatory contact scheme. I believe its been left intentionally open ended what other schemes may be supported by a server.
In my mind ACME servers wishing to support `tel` should come up with their own understanding of what parts of the relevant RFCs they support and use the `unsupportedContact` and `invalidContact` errors as appropriate based on the `tel://` contacts received. I don't think there is value trying to create a subprofile of `tel` for ACME use that is defined in the ACME draft. - cpu On Fri, Nov 17, 2017 at 11:12 AM, Logan Widick <[email protected]> wrote: > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
