Subject: [Iptel] Swallows or Spitz?

From: lconroy <[email-masked]>
Date: Sun, 15 Apr 2007 21:25:13 +0100

Hi again folks,
  I'm starting a whole (obviously) new thread with this message,
as it isn't directly related to the ISDN parameter content discussion.

RFC 4715 covers isdn subaddress typing. All is good.

The -00 of the individual draft has been around since 3rd March 2006,
and it whizzed through the IESG (without stopping in IPTEL for a LC)
to be released as an RFC in November. I note that in going through
the IETF & IESG it overtook the tel-reg draft in the process.

Now the bad news - RFC 4715 is INFORMATIONAL.

 From the latest tel-reg draft (the one specifying how to register tel:
parameters):
"  The tel URI parameters and values for these parameters MUST be
    documented in a standards-track RFC in order to be registered by
    IANA.  This documentation MUST fully explain the syntax, intended
    usage, and semantics of the parameter.  The intent of this
    requirement is to assure interoperability between independent
    implementations, and to prevent accidental namespace collisions
    between implementations of dissimilar features."

We have what seems to be a perfectly usable tel parameter for isdn
subaddress typing that is informational. Priceless.

So... Is 4715 going to be re-categorised on the standards-track, or
is the tel-reg draft going to be re-written to permit Informational
specifications for parameters that are to be registered with IANA?

[I'm as bad as anyone else - I didn't notice that it was Informational
until I looked at the RFC-editor announcement, and then promptly forgot
about it - duh !]

all the best,
   Lawrence

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 21:28:55 -0700

> specifications for parameters that are to be registered with IANA?

Actually this is pretty common when a registry gets created after the  
fact - often the stuff in it is sort of eclectic. My proposal would  
be to just do nothing - i.e. keep 4715 as information and put it in  
the registry anyways. The tel-reg draft describes what existing  
things already exist in the name space and what is required to add  
new ones.

When I ask myself what harm of interoperability or harm to the  
network will this cause - I come up with pretty much it is OK to just  
leave it like it is.

As you point out, there is no ideal solution here.

Cullen