Here is a PR to remove the "tel" contacts from the examples: https://github.com/ietf-wg-acme/acme/pull/353
In the PR, I am assuming that the ACME servers can support additional contact schemes (schemes not defined in ACME specs) but must document (somehow) what subsets of what additional schemes are supported. However, I haven't added any text indicating this assumption. I also haven't added any text indicating how the subsets of the additional contact schemes can be documented. Is this assumption correct? If so, should the assumption be documented any further in the spec? If so, what would be the best way to document this assumption further? Logan On Fri, Nov 17, 2017 at 11:17 AM, Daniel McCarney <[email protected]> wrote: > 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
