Subject: RE: [rohc] sigcomp issue list

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Sat, 13 Apr 2002 00:48:14 +0200

Hans,

Could you please update the list and clarify what actions have been taken.
Under "action", you now mostly list "responses", while I would also like
to see what has been changed in the drafts, if anything has been changed.
E.g. for the first issue, has this text been corrected???

Others, please look at this list and let us together agree to close the
issues that have been resolved.

BR
/Lars-Erik

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: den 10 april 2002 09:11
> To: [email-masked]'
> Subject: RE: [rohc] sigcomp issue list
> 
> 
> Hi, 
> 
> The current sigcomp issue list can be found at:
> http://standards.ericsson.net/hanhan/SigComp-issue-list-10thMarch.htm
> 
> This is a cut and paste summary of the work that the authors 
> have done when trying to close the issues.
> Take a look and see what you think so that we can close the 
> issues and submit the updated SigComp and SigComp-extended drafts.
> 
> BR
> /Hans H
> 
> > -----Original Message-----
> > From: Dr. Carsten Bormann [mailto:[email-masked]]
> > Sent: den 18 mars 2002 20:30
> > To: Dr. Carsten Bormann; [email-masked]
> > Subject: RE: [rohc] sigcomp issue list
> > 
> > 
> > Sigcompers,
> > 
> > I have compile some information from the various issues 
> > posting that have
> > been on the mailing list.
> > I hope this is a useful recap for people preparing for 
> > tomorrow's meeting.
> > I'm not claiming any of this is authoritative.
> > If you reply (please do), please change the subject to 
> "sigcomp issue
> > xxx-nn", where xxx-nn is the issue number.
> > 
> > Gruesse, Carsten
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked] (Dr. Carsten Bormann)
Date: 13 Apr 2002 10:27:26 +0200

I would propose a slightly more elaborate format for the issues list,
as exemplified by the following three examples.
In particular, I'd like to see a relatively small number of "states"
an issue can be in, which need to mesh with a RFC2026/2418 view of the
standards process.

Gruesse, Carsten

PS.: Oh, and please demicrosoftize (as exemplified, too).

________________________________________________________________________
 lejo-1 : Resolution proposed in current editors' working document
_________________________________
Issue:

In section 3.1 (page 9), it is written that SigComp usage is indicated
by using different port numbers. Did we not agree that this is one
option, but not necessary the way it is done. SigComp essages are now
self-identifiable.

_________________________________
Discussion:

Carsten: I believe the consensus is that Sigcomp should be open to a
number of ways to do the multiplexing; sigcomp itself contributes
identifiable messages, but using port numbers or some other scheme
definitely remains possible.

SigComp-05a messages are self-identifiable

I have one small question on this issue. SigComp messages are
recognizable from UTF-8 encoded text because of the following:

"Now, since RFC2044 (October 1996), Unicode has been decided to stop
at 0010 FFFF"

However I can't find a mention of this in the latest RFC on the
subject [RFC-2279]. Did I miss it in the RFC, or is there a separate
document on the subject that we could reference in SigComp?

Carsten: This was not done in IETF space, but in the Unicode/JTC1-SC2
environment.  See http://std.dkuug.dk/JTC1/SC2/WG2/docs/n2175.htm
By the way, a good intro into Unicode is at
http://oss.software.ibm.com/icu/userguide/unicodeBasics.html

_________________________________
Action:

Text in 3.1 now says:

   All SigComp messages contain a prefix that does not occur in UTF-8
   encoded text messages [RFC-2279], so for applications which use this
   encoding it is possible to multiplex uncompressed application
   messages and SigComp messages on the same port. Applications can
   still reserve a new port specifically for SigComp however (e.g. as
   part of the discovery mechanism).

________________________________________________________________________
 lejo-2 : Proposed: No action needed
_________________________________
Issue:

Use of static dictionaries, how is that envisioned? First of all, I
assume it should be mentioned and explained, e.g. when per-message
compression is defined. Further, 6.3.3 may be interpreted as if static
dictionary usage is about announcing certain pre-defined states. Is
that a good approach? Should one not define a static dictionary for
each SigComp application, e.g. SIP, that must be used as a minimum?

_________________________________
Discussion:

Carsten: The sense of the IETF-3GPP ad-hoc on this was, yes, we should
define one such static dictionary for SIP.  It is static in that it
really does not change, even if further extensions get added to SIP.

A design team comprising Carsten, Richard and some SIP/SDP/SIPPING
people will construct a static dictionary for use with SIP/SDP.

This is not part of SigComp.

I used the example of the SIP static dictionary in Section 3.3.3 when
explaining about locally available state.  It would be useful to add a
specific reference to the dictionary (assuming we decide to publish as
a separate document).

_________________________________
Action:

No action needed in sigcomp itself.

________________________________________________________________________
 lejo-3 : Resolution proposed in current editors' working document
_________________________________
Issue:

We must standardize how SigComp is used for e.g. SIP (at least).
This includes default values for all application parameters, the
mechanism used to separate SigComp/SIP from normal SIP messages, and
maybe a mandatory static dictionary.

_________________________________
Discussion:

Carsten: See lejo-2 above.
For the parameters, let's see how they distill (cabo-15); once this is
done, it may be almost obvious what to use for SIP.
The whole thing should be specified in an annex to sigcomp, to clearly
identify it as something that is separate from sigcomp itself, or,
alternatively, as a separate draft.

Default parameter values are defined in SigComp-05a.

See also lejo-2

We managed to dispose of every parameter apart from the ones that can
be announced using the SigComp feedback mechanism.  Therefore, we
normally take the default value for each parameter to be the minimum
possible (after all, we can always announce higher values if they are
available).

The only exception to the above is if we feel that for a particular
application, it would be useful to offer additional resources as
mandatory.  For example we believe that a mandatory static dictionary
is useful in SIP/SDP.  We'll have to standardize these additional
resources on a case-by-case basis as we are doing for SIP/SDP.

_________________________________
Action:

Text in 3.3 now specifies the default values for parameters; these
should be useful for SIP/SDP compression as they are.