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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Feb 2012 12:46:16 +0100

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Feb 2012 10:12:10 -0500

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:
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Feb 2012 17:09:47 +0100

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: 29 February 2012 15:12
> To: [email-masked]
> Subject: Re: [cuss] Default content and encoding in ISDN package
> 
> > 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:
> >
> a
> a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Feb 2012 11:24:36 -0500

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Feb 2012 17:31:55 +0100

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.

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.

Keith

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 29 February 2012 16:25
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> > 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.
> >
> > 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?
> >
> > 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.
> >