Subject: RE: [Enum] "Enumservices" and RFC 3953

From: "Stastny Richard" <[email-masked]>
Date: Thu, 27 Jan 2005 13:20:16 -0500

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 tme 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

---

From: lconroy <[email-masked]>
Date: Thu, 27 Jan 2005 19:21:43 -0500

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:

---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 29 Jan 2005 08:16:09 -0500

I will take this up with IANA.
    paf
On Jan 27, 2005, at 19: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."

- 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 tme 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.