Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

From: <[email-masked]>
Date: Tue, 14 Feb 2012 07:35:02 +0100

Dear all,
I would like to know if there were any assumptions made on the issue discussed over the last weeks.

1. Package parameter default
2. HEX encoding

Is there any stuff that will go into the draft?

Thank you and Best Regards

Roland

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 16 Feb 2012 10:52:28 +0100

Hi Roland,

I commented on these issues on the cuss list. Here is my understanding of the current state of the discussion.

It was confirmed that isdn-uui is the default that is applicable when the package "parameter" is absent. It was discovered that there is related wording in the framework draft. However, in Keith´s isdn-uui draft there is wording that a sender shall supply the package parameter, which may be in contradiction. There was no response to my proposal to change the isdn-uui draft in this respect. I believe Orange commented the same thing independently. I hope this will be fixed in the next version of Keith´s draft.

I also commented that the definition of the hex encoding in the framework draft is very unclear. There were positive responses and I expect this to be improved in the next version of the framework draft.

My proposal to allow only Upper-case characters in the hex encoding was controversial. There were two voices in favor and two voices against this. More opinions would help.

There was also no very clear conclusion on my proposal to allow only "token" (rather than "quoted string") for hex encoding. Again, more opinions could help.

Thomas

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 7:35 AM
To: [email-masked]; Belling, Thomas (NSN - DE/Munich); [email-masked]; [email-masked]; [email-masked]
Subject: AW: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

Dear all,

Roland

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 16 Feb 2012 10:57:17 +0000

Greetings,

Can the editors and WG chairs please respond to the queries in this thread?

Thank you,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Services, Inc.
[email-masked]
+1-609-903-3360

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Belling, Thomas (NSN - DE/Munich)
Sent: Thursday, February 16, 2012 4:52 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

Hi Roland,

Thomas

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 7:35 AM
To: [email-masked]; Belling, Thomas (NSN - DE/Munich); [email-masked]; [email-masked]; [email-masked]
Subject: AW: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

Dear all,

Roland
_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss

---

From: <[email-masked]>
Date: Thu, 16 Feb 2012 14:40:13 +0100

Hello,

Yes, we would like, if possible, to get the feedbacks from the editors on the different received comments made after reviewing the drafts (draft-ietf-cuss-sip-uui-04.txt and also draft-ietf-cuss-sip-uui-isdn-01.txt, cf cuss mailing list) in order to have some exchanges on the different topics addressed and get a conclusion for each of them. 

Thanks in advance.

Regards,

Celine Serrut-Valette
Orange Labs 

-----Message d'origine-----
De : DOLLY, MARTIN C [mailto:[email-masked]] 
Envoyé : jeudi 16 février 2012 11:57
À : Belling, Thomas (NSN - DE/Munich); [email-masked]; SERRUT-VALETTE Celine RD-CORE-ISS; [email-masked]; [email-masked]; [email-masked]
Objet : RE: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

Greetings,

Thank you,

Martin Dolly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Belling, Thomas (NSN - DE/Munich)
Sent: Thursday, February 16, 2012 4:52 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

Hi Roland,

Thomas

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 7:35 AM
To: [email-masked]; Belling, Thomas (NSN - DE/Munich); [email-masked]; [email-masked]; [email-masked]
Subject: AW: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

Dear all,

Roland

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Feb 2012 11:23:33 -0600

> Can the editors and WG chairs please respond to the queries in this

Martin: As it so happened, Enrico and I had touched base with
the editors of the two pending documents yesterday; the loose
deadline for submitting the updated revisions to the drafts
exoired yesterday [1].

A revision to the two drafts should appear soon on the list,
which we hope will lead to a larger dialogue with the editors
to close the comments in [2].

So ... please stay tuned.

[1] http://www.ietf.org/mail-archive/web/cuss/current/msg00328.html
[2] http://www.ietf.org/mail-archive/web/cuss/current/msg00343.html

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Alan Johnston <[email-masked]>
Date: Fri, 17 Feb 2012 09:45:48 -0600

We are working on updates to the drafts.

I think we can fix the ISDN package concern by changing the MUST to a SHOULD.  Since the absence of the package parameter implies the ISDN package, there is no interoperability problem here.

The hex encoding issue does have interoperability problems.  Paul and I have already explained why limiting hex letters to upper case is not a good idea, nor is it commonly done.

Also, it seems that every version of the mechanism draft (both the working group draft and my individual draft), except one, has an example showing lower case hex letters in it.  There are existing implementations that use lower case hex letters.  I don't see how we can change this now without causing even more problems.  

- Alan -

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 17 Feb 2012 17:17:14 +0100

Dear Alan,

The argument "we do it like this in other protocols" brought forward earlier was far from convincing in my view. However, for me your new arguments that you are aware of existing implementations using lower case characters and there are also such examples in some draft versions is more compelling.

Thomas

-----Original Message-----
From: ext Alan Johnston [mailto:[email-masked]] 
Sent: Friday, February 17, 2012 4:46 PM
To: Belling, Thomas (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

- Alan -

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Feb 2012 11:49:25 -0500

> Also, it seems that every version of the mechanism draft (both the working group draft and my individual draft), except one, has an example showing lower case hex letters in it.  There are existing…

I am in full agreement with what Alan says above.

Re token vs. quoted string:

IMO it is better for implementation if this is viewed as a lexical 
issue, separated from the semantics. Specifically, the content of the 
parameter is the content of the parameter, quoted or not. The difference 
is that quoted strings can contain a larger range of characters than 
unquoted strings (tokens) can. So:
- the quoted string "abcd" can also be represented as the token abcd,
- but the quoted string "a b c d" cannot be represented as a token.

So as long as the encoding is hex, which contains only characters that 
may appear in a token, the value can be represented either as a token or 
a quoted string.

That means that the underlying implementation, after parsing the header, 
need not remember whether the parameter was represented as a quoted 
string or a token.

Or we could simply not allow tokens at all - only allow quoted strings.

I still think it would be useful to define a "string" encoding as an 
alternative to hex. I have seen a number of cases where the UUI value 
(including the discriminator byte) consisted of nothing but printable 
ascii characters. In such cases it would certainly make the messages 
easier to read.

But that is only of major use in debugging and documentation of 
examples, so its not a major justification. So I am content to postpone 
or ignore that, since nobody else seemed enamored by this.

	Thanks,
	Paul

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 17 Feb 2012 18:28:34 +0100

Dear Paul,

It is understood that for future encodings that might e.g. allow to
include a simple ASCII string as data, quoted string is required.

> That means that the underlying implementation, after parsing the
header, need not remember whether the
> parameter was represented as a quoted string or a token.

My proposal to use only token for hex encoding also did not put any such
requirement on the implementation.

> Or we could simply not allow tokens at all - only allow quoted
strings.

This would cause real backward compatibility issues.

Thomas

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, February 17, 2012 5:49 PM
To: Alan Johnston
Cc: Belling, Thomas (NSN - DE/Munich); [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

On 2/17/12 10:45 AM, Alan Johnston wrote:
> I think we can fix the ISDN package concern by changing the MUST to a
SHOULD.  Since the absence of the package parameter implies the ISDN
package, there is no interoperability problem here.
>
> The hex encoding issue does have interoperability problems.  Paul and
I have already explained why limiting hex letters to upper case is not a
good idea, nor is it commonly done.
>
> Also, it seems that every version of the mechanism draft (both the
working group draft and my individual draft), except one, has an example
showing lower case hex letters in it.  There are existing
implementations that use lower case hex letters.  I don't see how we can
change this now without causing even more problems.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Feb 2012 13:00:54 -0500

Thomas,

I am not happy to establish a precedent that we can't refine a draft 
prior to publishing it as an RFC because of deployed implementations of 
earlier drafts. Drafts are called that because that is what they are - 
"drafts". There is no promise that backward compatibility will be 
maintained from one draft to the next.

I also don't see much of a compatibility issue in these cases anyway. 
And both the upper/lower case hex issue and the token vs. quoted string 
issue present exactly the same challenges for your deployed systems. As 
long as the published version allows both lower and upper case, and both 
tokens and quoted strings, new implementations will *accept* what you 
say your deployed systems do. And its perfectly legal for new versions 
of those deployed systems to continue producing what they do now, so 
they will be backward compatible with their older versions. So all you 
need do is upgrade your deployed systems to be conforming to the 
published spec, and *then* they will be able to interoperate with 
implementations that never supported the "subset" that you have deployed.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Feb 2012 23:21:19 +0100

Hi Paul,

In general I agree with you. People, when implementing drafts, need to be aware that things may change.

But, in this case, the main problem is that the work has been going on forever. We can argue about the reaons, and I am not putting blames on anyone, simply identifying a fact.

How long can we expect people to wait until they start to implement and deploy things?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Friday, February 17, 2012 8:00 PM
To: Belling, Thomas (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [cuss] proposed changes for draft-ietf-cuss-sip-uui-04.txt

Thomas,

        Thanks,
        Paul