[cuss] "isdn-uui" versus "isdn-network"

["Vijay K. Gurbani" <[e-mail]>]

Folks:

The forward movement of draft-ietf-cuss-sip-uui-isdn has been bogged
down.  While the issue that stopped its movement is not as grandiose
as the MTI discussion on the rtcweb WG (thankfully!), nonetheless, it
must get resolved to proceed further.

At issue is the fact that draft-ietf-cuss-sip-uui-isdn uses the value of
"isdn-uui" for the "purpose" header field parameter.  Older versions of
the draft used the value "isdn-network".  Consequently, there are some
implementations that use "isdn-network" and doubtlessly, for some valid
reasons these implementations are not amenable to change.

Therefore, it was proposed that a note be added that allows senders to
use either "isdn-network" or "isdn-uui" and the receiver be prepared
to receive either of the value.

The big question was whether this note appear as informative or
normative?

If normative, then the ABNF would need to modified to support "isdn-
network" generation as well.  If informative, then this note sets a
precedence that parameters defined in Work In Progress Internet-Drafts
be supported in perpetuity.  The argument for not supporting "isdn-
network" by updating the ABNF is that it introduces a certain amount of
uncertainty: how does a sender decide which representation of the
parameter to send out?  It can randomly choose one, of course, but this
just seems a bad protocol design pattern.

The chairs, the AD, the draft author and a few WG members had a
a hallway conversation in the Vancouver IETF to close this issue.

The outcome of this conversation is that "isdn-network" is an artifact
that draft-ietf-cuss-sip-uui-isdn is NOT required to carry on forward.
Allowing the daft to support an older representation simply sets a
precedent that will engender a tough ride as the draft sails through
the IESG.

As such, "isdn-uui" is the only legal value.

We will now proceed to issue a WGLC on the draft.

Thanks,

Vijay K. Gurbani and Enrico Marocco.