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

[Andrew Allen <[e-mail]>]

I have some sympathy for Bruno's position. He is merely asking to align with the principle of "Be strict in what you send, but generous in what you receive".

I don't think this creates a bad precedent (similar things have been done already - just  take a look at the more complex backwards compatibility being defined now in INSIPID) and whatever is done always requires consensus.

At IETF we hold in high regard running code and hope and expect that people will implement drafts ahead of publication. Given the time this draft has taken to progress it shouldn't be a surprise that there is now deployed equipment based on earlier versions of the draft. In many cases work in IETF has originated based on what was already done outside IETF (e.g. Jabber) and backwards compatibility with pre-standard kit is often a design goal.

I don't think acceptance of a pre-standard  token value is too much to ask to ensure interoperability. That's why we create standards to ensure interoperability not to be an obstacle to it.

Andrew

-----Original Message-----
From: cuss [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, November 20, 2013 11:51 AM
To: Vijay K. Gurbani; [e-mail]
Subject: Re: [cuss] "isdn-uui" versus "isdn-network"

Vijay,

I don't know who had been invited to the hallway conversation you mentioned but to be honest, I'm really surprised by the decision made. 

Indeed, there were no objections on the cuss list to the latest wording (informative) proposed on Sept 12 for the text to be added to the document and I don't really understand why the proposal was not implemented right away in the I-D actually! 
http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html

Moreover, all people who have been active on this topic on the cuss mailing list either supported the addition of an informative text or have asked questions for clarification. I have not seen any explicit objection.

So, how can a hallway conversation lead to such a U-turn? 

Furthermore, I'd like to understand why people have concerns with adding the proposed informative statement in the CUSS document but seem to be happy with a similar note in draft-ietf-bfcpbis-rfc4583bis

  Note: In [15] 'm-stream' was erroneously used in Section 10.
   Although the example was non-normative, it is implemented by some
   vendors and occurs in cases where the endpoint is willing to act as
   an server.  Therefore, it is RECOMMENDED to support parsing and
   interpreting 'm-stream' the same way as 'mstrm' when receiving.

Bruno

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part 
> de Vijay K. Gurbani Envoyé : lundi 11 novembre 2013 18:39 À : 
> [e-mail] Objet : [cuss] "isdn-uui" versus "isdn-network"
> 
> 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.
> _______________________________________________
> cuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cuss

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
cuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cuss
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.