Subject: Re: [cuss] Default content and encoding in ISDN package

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 1 Mar 2012 11:20:33 +0100

Hi Paul,

Compatibility consideration seem to be unknown terrain in IETF (not
compatibility between draft versions but RFCs this time)???

Suppose at some stage another encoding is defined and a sender uses this
to send isdn-uui contents. Then it would risk that a receiver only
supporting the hex encoding cannot interpret it.
So we need strict wording that the sender shall use hex encoding for
isdn-uui contents.
And what would be the point of having wording that suggest that a
receiver may support other encodings for isdn-uui contents if they will
never be sent?

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Paul Kyzivat
Sent: Wednesday, February 29, 2012 4:12 PM
To: [email-masked]
Subject: Re: [cuss] Default content and encoding in ISDN package

Before further tweaking the wording, I'll ask a question:

Suppose we eventually define other encodings. Is there any reason that
those other encodings could not be used with isdn-uui, assuming the
sender and the recipient support them?

I would be inclined to be a little less rigid about rejecting other
encodings. (IOW I think that support for encodings should be orthogonal
to support for different content values.)

	Thanks,
	Paul

On 2/29/12 6:46 AM, DRAGE, Keith (Keith) wrote:
> The mechanism draft uses the term default a number of times in regard
to the "content" and "encoding" header field parameters and indicates
the packages will define the default. In the ISDN package, the only
point this really gets mentioned is in the IANA registration, although
it is otherwise covered. I proposed to amend the following section 9
text:
>
>     When sending UUI, the sending SIP entity MAY, but need not,
include a
>     "content" header field with a value set to "isdn-uui".  A
receiving
>     SIP entity MUST ignore a received User-to-User header field if the
>     "content" header field parameter is present and the value is some
>     other value that "isdn-uui".
>
>     When sending UUI, the sending SIP entity MAY, but need not,
include
>     an "encoding" header field with a value set to "hex".  A receiving
>     SIP entity MUST ignore a received User-to-User header field if the
>     "encoding" header field parameter is present and the value is some
>     other value that "hex".
>
> As below:
>
>     The default and only content defined for this package is
"isdn-uui".
>     When sending UUI, the sending SIP entity MAY, but need not,
include a
>     "content" header field with a value set to "isdn-uui".  A
receiving
>     SIP entity MUST ignore a received User-to-User header field if the
>     "content" header field parameter is present and the value is some
>     other value that "isdn-uui".
>
>     The default and only encoding defined for this package is "hex".
>     When sending UUI, the sending SIP entity MAY, but need not,
include
>     an "encoding" header field with a value set to "hex".  A receiving
>     SIP entity MUST ignore a received User-to-User header field if the
>     "encoding" header field parameter is present and the value is some
>     other value that "hex".
>
> Does anybody have objections to this change, or indeed a better
wording?
>
> Regards
>
> Keith
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Mar 2012 14:53:36 +0100

I've changed the name of the thread, because I think we do need a more general discussion of compatibility, both forward and backward.

At the end of the day, Paul is hinting at that, and all protocols should consider it.

>From ITU-T Q.1400:

"Forward compatibility mechanisms are defined as a scheme to enable a version of a protocol to communicate effectively with and interwork with future versions of the protocol. That is, a version of a protocol should not restrict future protocols from providing extra capabilities.

Backward compatibility rules are defined as a scheme to ensure that future versions of the protocol will be able to send protocol messages to the previous version which will be understood and fully processed by the node supporting the previous version. That is, future versions of a protocol must allow earlier versions to operate with it and not reduce the earlier version's service level."

At the moment the only defined compatibility mechanism defined is the package mechanism, i.e. if you want to define and use a new capability you define a new package. This 1) clearly indicates the capability level that is needed to be supported, 2) can be used in parallel with the older package where it is not clear what is supported, 3) Using media feature tags can route the call to the appropriate supporting capability.

Do we need anything beyond this?

Some compatibility mechanisms work by negotiating the capability support before initiating the protocol exchange. However may of the use cases for UUI transfer are dependent on transfer of the first data with the INVITE request of a SIP dialog. Therefore it is impractical to perform that negotiation before data is sent, except perhaps in a preliminary OPTIONS request.

Other compatibility mechanisms divide the protocol into categories, e.g.
-	discard without notification
-	discard with notification
-	reject the entire request

At the moment the UUI mechanism is entirely discard without notification. That has been decided not on the need for a compatibility mechanism, but rather on the auxiliary nature of the data, i.e. if a discard occurs, we do not expect it to occur because I'm using an extension to an existing package that the remote side does not understand, but rather because it has proved technically impossible to transfer the data, i.e. I've sent too much data, sent it at the wrong time, or sent it to something that cannot receive the data.

I'd represent at the moment that if we want extensibility within the package, then we need to reevaluate this decision.

Otherwise I believe we should limit extensibility to the package mechanism, i.e. if we want a new encoding within a package, we should define a new package that contains that new encoding.

Whatever we decide, I think the generic mechanism document should include a section discussing these issues. It does not seem to at the moment.

Please discuss.

Keith

> Belling, Thomas (NSN - DE/Munich)
> Sent: 01 March 2012 10:21
> To: ext Paul Kyzivat; [email-masked]

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 1 Mar 2012 16:38:33 +0100

Hi Keith,

I believe the content and encoding parameters are also introduced only
for forward compatibility (at least only a single value is applicable
for each of those parameters for ISDN-UUI).

But I agree that the main forward compatibility mechanism in the
framework draft is the package parameter, and I could even imagine that
the content and encoding parameters are not required at this stage, but
could be defined by RFCs defining additional packages, if they really
identify a need for such parameters. The ABNF allowing for a
"generic-param" should allow for additional parameters to be defined at
a later stage anyway.

But I am also concerned that such fundamental redesigns at this stage
could delay the approval of the draft even more and would thus suggest
that we restrict ourselves to correction and smaller improvements.

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext DRAGE, Keith (Keith)
Sent: Thursday, March 01, 2012 2:54 PM
To: [email-masked]
Subject: [cuss] Compatibility: was Default content and encoding in
ISDNpackage

I've changed the name of the thread, because I think we do need a more
general discussion of compatibility, both forward and backward.

At the end of the day, Paul is hinting at that, and all protocols should
consider it.

>From ITU-T Q.1400:

"Forward compatibility mechanisms are defined as a scheme to enable a
version of a protocol to communicate effectively with and interwork with
future versions of the protocol. That is, a version of a protocol should
not restrict future protocols from providing extra capabilities.

Backward compatibility rules are defined as a scheme to ensure that
future versions of the protocol will be able to send protocol messages
to the previous version which will be understood and fully processed by
the node supporting the previous version. That is, future versions of a
protocol must allow earlier versions to operate with it and not reduce
the earlier version's service level."

At the moment the only defined compatibility mechanism defined is the
package mechanism, i.e. if you want to define and use a new capability
you define a new package. This 1) clearly indicates the capability level
that is needed to be supported, 2) can be used in parallel with the
older package where it is not clear what is supported, 3) Using media
feature tags can route the call to the appropriate supporting
capability.

Some compatibility mechanisms work by negotiating the capability support
before initiating the protocol exchange. However may of the use cases
for UUI transfer are dependent on transfer of the first data with the
INVITE request of a SIP dialog. Therefore it is impractical to perform
that negotiation before data is sent, except perhaps in a preliminary
OPTIONS request.

At the moment the UUI mechanism is entirely discard without
notification. That has been decided not on the need for a compatibility
mechanism, but rather on the auxiliary nature of the data, i.e. if a
discard occurs, we do not expect it to occur because I'm using an
extension to an existing package that the remote side does not
understand, but rather because it has proved technically impossible to
transfer the data, i.e. I've sent too much data, sent it at the wrong
time, or sent it to something that cannot receive the data.

I'd represent at the moment that if we want extensibility within the
package, then we need to reevaluate this decision.

Otherwise I believe we should limit extensibility to the package
mechanism, i.e. if we want a new encoding within a package, we should
define a new package that contains that new encoding.

Whatever we decide, I think the generic mechanism document should
include a section discussing these issues. It does not seem to at the
moment.

Please discuss.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Belling, Thomas (NSN - DE/Munich)
> Suppose at some stage another encoding is defined and a sender uses 
> this to send isdn-uui contents. Then it would risk that a receiver 
> only supporting the hex encoding cannot interpret it.
> receiver may support other encodings for isdn-uui contents if they 
> will never be sent?
> 
> Thomas
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of ext Paul Kyzivat

> encodings. (IOW I think that support for encodings should be 
> orthogonal to support for different content values.)
> 
> 	Thanks,
> 	Paul
> 
>

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 1 Mar 2012 16:48:13 +0100

I forgot to add my conclusion:
We should stick to the "package" as main forward compatibility
mechanism.

We already have guidelines for package design that say that applicable
content values and encoding need to be considered when defining a
package. Is that not enough clarification for those parameters?

Thomas

-----Original Message-----
From: Belling, Thomas (NSN - DE/Munich) 
Sent: Thursday, March 01, 2012 4:39 PM
To: 'ext DRAGE, Keith (Keith)'; [email-masked]
Subject: RE: [cuss] Compatibility: was Default content and encoding in
ISDNpackage

Hi Keith,

Thomas

-----Original Message-----

Please discuss.

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 13:52:09 -0500

On 2/29/12 11:31 AM, DRAGE, Keith (Keith) wrote:
> No I don't believe I am.
>
> All I am saying is that the same analysis of the issue and the resultant questions apply to both. That doesn't preclude people answering those questions I have asked with different answers.
>
> And certainly the handling is in two distinct and separate paragraphs at the moment, which can be independently modified.
>
> There are some commonalities - for example neither of of them have an equivalent in the ISDN protocols that they can be interworked to.

I don't think there need be *any* relationship between the encoding 
parameter in sip and how the data is encoded in ISDN. There is only one 
choice of encoding in ISDN - binary. We could have any number of 
encodings in sip, so long as they can each be converted to/from the 
binary form used in ISDN. When going from sip to ISDN nothing more is 
needed. When going from ISDN to sip, one encoding needs to be selected. 
I don't have any particular problem with specifying that in this case 
hex is to be used.

> And the other commonality is that they both probably need to be discussed from the wider viewpoint of what is the generic handling in this and all future packages.

When I first proposed that we make provision for multiple encodings, I 
anticipated that we would be defining more than one initially. But there 
was not much interest in that. (Even though I've seen some evidence that 
an "ascii" encoding might be quite useful.)

Whether other encodings will be desired for other content remains to be 
seen.

I remain concerned that the ISDN package, while necessary for backward 
compatibility, is not a good model for interoperability for the future. 
It has no way to ensure that the sender and the recipient have a common 
understanding of the format of the information being passed. Ideally 
each application would use some combination of package and content names 
to handle that. But it seems people don't want to discuss that, at least 
yet.

	Thanks,
	Paul

>> From: Paul Kyzivat [mailto:[email-masked]]
>> Sent: 29 February 2012 16:25
>> To: DRAGE, Keith (Keith)
>> Cc: [email-masked]
>> Keith,
>> You seem to be treating "content" and "encoding" analogously below.
>> IMO they are of a different character and need to be considered
>> independently. (I see significant parallels between content/encoding and
>> MIME Content-Type/Content-Encoding.)
>>
>> In particular, I would hope that an implementation that supports both
>> multiple content values and multiple encoding values would implement
>> them independently, so that any supported encoding could be used with
>> any supported content.
>>
>> 	Thanks,
>> 	Paul
>>
>> On 2/29/12 11:09 AM, DRAGE, Keith (Keith) wrote:
>>> At the moment additional valued are not needed for the ISDN package, and
>> I don't see how they would be used in the future given the constraint on
>> interworking - what is sent must be interworkable.
>>>
>>> The current wording of the generic document is that the package (and
>> therefore the package document) should define which content values and
>> which encoding values can be used, and which is the default.
>>>
>>> So in terms of the words I proposed to change that change would appear
>> to be needed.
>>>
>>> You question is a different issue on text that was already in the -00
>> version of the author draft.
>>>
>>> In response to that, I guess there are three considerations:
>>>
>>> 1)	If the content or encoding is something I do not understand at all,
>> then the text as written is the only possible action. For example, I
>> should not treat a received content value of "xxxx" as if it was "uui-
>> isdn".
>>>
>>> 2)	If the content or encoding is something defined as applicable in
>> another package, that is also implemented by the UA, then I guess the
>> question is can the UA place a sufficiently valid interpretation on that
>> in order to render it? I am not entirely convinced it can but seek other
>> opinions.
>>>
>>> 3)	If the content or encoding is something defined as applicable in a
>> update or replacement RFC for the same package, then we surely need some
>> rules for that occurring in the generic mechanism draft. What are those
>> rules?
>>>
>>> We have agreed in the past that extensions to both these values have to
>> be defined by RFC (general).
>>>
>>> I'd also note that the general principle of this package (uui-isdn) at
>> least is throw away if it does not meet the rules or cannot be
>> interworked. Throw away if too long. Throw away if in wrong message. Etc.
>> If you wanted to do something else for many of these, doesn't that make it
>> a different package.
>>>
>>> What does the working group want?
>>>
>>> Regards
>>>
>>> Keith
>>>
>>>
>>>> Paul Kyzivat
>>>> Sent: 29 February 2012 15:12
>>>> To: [email-masked]
>> to
>>>> the "content" and "encoding" header field parameters and indicates the
>>>> packages will define the default. In the ISDN package, the only point
>> this
>>>> really gets mentioned is in the IANA registration, although it is
>>>> otherwise covered. I proposed to amend the following section 9 text:
>>>>>
>>>> a
>>>>>       The default and only content defined for this package is "isdn-
>> uui".
>>>> a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 14:02:12 -0500

> receiver may support other encodings for isdn-uui contents if they will

See my reply to Keith.

Unfortunately, using UUI in the ISDN world requires a common 
understanding between sender and receiver of what data format is being 
conveyed. (In theory it seems that the protocol discriminator byte is 
intended to say *something* about the remainder of the data, but not much.)

What encoding to use could just be part of that common understanding. 
While that isn't good, its perhaps not worse than it already is. But 
perhaps the difference is that when one end is sip and the other is 
really ISDN, then its the GW that needs to know the encoding but the 
endpoint that needs to know the format. So there is an added requirement 
for the sender to know the capabilities of the intervening GW.

We could address this by defining a literal character encoding now in 
addition to the hex encoding, and expecting everything to support both.

	Thanks,
	Paul

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 5 Mar 2012 10:44:13 +0100

Dear Paul,

Your explanations were more related to the content than the mere
encoding.

You are right that in ISDN the protocol discriminator does not tell too
much about the content, but we are emulating this service and (as you
say) will frequently interwork withg ISDN devices where we can hardly do
more.

But to address this concern, we could consider a more liberal usage of
the content parameter (e.g. with privat values) to say more about the
content should the peer understand. This would be lost in ISUP
interworking.

Thomas

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, March 01, 2012 8:02 PM
To: Belling, Thomas (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [cuss] Default content and encoding in ISDN package

See my reply to Keith.

Unfortunately, using UUI in the ISDN world requires a common
understanding between sender and receiver of what data format is being
conveyed. (In theory it seems that the protocol discriminator byte is
intended to say *something* about the remainder of the data, but not
much.)

	Thanks,
	Paul