Re: [Enum] "Enumservices" and RFC 3953
lconroy <lconroy@insensate.co.uk> Fri, 28 January 2005 00:21 UTC
From: lconroy <lconroy@insensate.co.uk>
Date: Thu, 27 Jan 2005 19:21:43 -0500
To: Stastny Richard <"Richard.Stastny at oefeg.at">
Subject: Re: [Enum] "Enumservices" and RFC 3953
In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46FAB7@oefeg-s04.oefeg.loc>
Message-ID: <d3ef1c771a23ab7ce1c187d935b26dde@insensate.co.uk>
MIME-Version: 1.0
Content-Type: text/plain
Status: R
Hi Richard, Klaus, Kim, all, Happy new year. Dead Right - the "E2U+blah" registrations are indeed wrong, in that they don't match the framework for registrations specified in RFC3761 section 3. That states that Enumservice registrations are based on type, with all sub-types and (generated) URI (schemes) being included in the registration. The type forms the apex of a namespace branch - there can be no other sub-types/URI schemes unless the "master" specification is updated/obsoleted. Tedious, but necessary. In the IANA tree specifications, conformance with RFC3761 is required, and the values put into the current IANA tree aren't. These normative specifications need to be precise, as otherwise the protocol is unclear. For example, at present, the IANA registration implies that a service string of the form "E2U+E2U+SIP", with a generated URI scheme of "sip:" is valid. It isn't. IMO, We should fix all the registrations ASAP. Looking at the ones with which I'm involved: As webft SHOULD be going through the IESG process, I'd suggest that we can change this during the Author's 48, assuming that ever occurs. Similarly, if the clarifications requested and provided for the msg draft have removed any reasonable remaining doubt, then we can ensure that the same is true for the individual service registrations included there too when that goes through Author's 48. I'll look through the Experiences draft to see if there's anywhere where the Enumservice strings could be ambiguous, but I don't think there is anything. I've heard no more issues raised, so from my perspective the current Experiences draft is complete. However, as the anointed Enumservices are RFCs already, does the errata mechanism need to be invoked? all the best, Lawrence On 27 Jan 2005, at 18:06, Stastny Richard wrote: Hi Kim and all, A bit of background - what is an "enumservice" ? There seems to be a conflict between RFCs. - RFC 3761 section 2.4.2 says "In other words, a non-optional "E2U" .... followed by 1 or more or more Enumservices which >indicate what class of functionality a given end point offers. Each Enumservice is indicated by an initial '+' character." So in an NAPTR record with field "E2U+pres", the 'pres' bit is the enumservice and we could potentially have >"E2U+servicea+serviceb". - However, RFC3953 describes in Section 4 the "E2U+pres" Enumservice. So in this case the enumservice is "E2U+pres". Is the enumservice the combination "E2U+pres" or the singular "pres" ? I also recognized this problem some time ago by looking at the IANA registrations for "enumservices", but I did not really follow-up. Maybe this is a good opportunity to do so, and the issue can be put on the agenda of the next IETF enum wg. The current registrations as shown in <http://www.iana.org/assignments/enum-services <http://www.iana.org/assignments/enum-services> > are inconsistent and are likely to cause confusion with implementors: The Service Name (which is not defined in the template of RFC3761 section 3.2.3 shows in some case "examples" of the "service-field", in some other cases the "type" of the enumservice. IMHO ALL current registrations including webft should be changed considering RFC3761: service-field = "E2U" 1*(servicespec) servicespec = "+" enumservice enumservice = type 0*(subtypespec) subtypespec = ":" subtype type = 1*32(ALPHA / DIGIT) subtype = 1*32(ALPHA / DIGIT) the "Enumservice Name" should be type or type:subtype (or type:subtype:subtype...) and ALL registrations should contain Type(s): and Subtype(s): it should therefore be e.g. Service Name: "H323" and NOT "E2U+H323" Type: "H323" - missing Subtype: N/A - missing URI Scheme(s): "h323:" Service Name: "SIP" and NOT "E2U+SIP" Type(s): "SIP" Subtype(s): N/A URI Scheme(s): "sip", "sips:" Service Name: "ifax:mailto" and NOT "E2U+ifax" Type: "ifax" Subtype: "mailto" URI Scheme: "mailto" Service Name: "pres" and NOT "E2U+pres" Type: "pres" - missing Subtype: N/A - missing URI Scheme(s): "pres:" Service Name: "web:http" and NOT "web" Type: "web" Subtype: "http" URI Scheme: 'http:' Service Name: "web:https" and NOT "web" Type: "web" Subtype: "https" URI Scheme: 'https:' Service Name: "ft:ftp" and NOT "ft" Type: "ft" Subtype: "ftp" URI Scheme: 'ftp:' I suggest that this proposal is considered by the responsible A-Ds and WG chairs and that IANA is contacted appropriately after a decision is made. best regards Richard Stastny _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum --------------------------------------- lawrence conroy |tel:+44-1794-833666 _______________________________________________ enum mailing list enum at ietf.org https://www1.ietf.org/mailman/listinfo/enum
- [Enum] "Enumservices" and RFC 3953 Fullbrook Kim (UK)
- RE: [Enum] "Enumservices" and RFC 3953 Klaus Darilion
- RE: [Enum] "Enumservices" and RFC 3953 Fullbrook Kim (UK)
- RE: [Enum] "Enumservices" and RFC 3953 Stastny Richard
- Re: [Enum] "Enumservices" and RFC 3953 lconroy
- Re: [Enum] "Enumservices" and RFC 3953 Patrik Fältström
- RE: [Enum] "Enumservices" and RFC 3953 Fullbrook Kim (UK)
- Re: [Enum] "Enumservices" and RFC 3953 Patrik Fältström