Subject: [Sipping] Last chance to comment on the conference package draft

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 07 Apr 2005 17:54:07 +0300

Folks,

Orit has put together a new revision of the conference package I-D 
addressing comments she received during its WGLC. Nobody has complained 
since this draft was released (see below).

If anybody thinks that this draft is not ready to be sent to the IESG at 
this point, please speak now. Otherwise, we will request its publication 
(together with the other three conferencing documents) on April 14th.

Thanks,

Gonzalo

-------- Original Message --------
Subject: RE: [Sipping] I-D 
ACTION:draft-ietf-sipping-conference-package-10.txt
Date: Tue, 29 Mar 2005 08:45:57 -0800
From: Orit Levin <[email-masked]>
To: <[email-masked]>

Hello all,

Below is the summary of all changes from -09:

1. Based on the feedback from a couple of readers and with Henning's
help, we have restructured Section 5 and added more narrative
description to it. We hope that it became more readable this way.

2. Based on the feedback from Henning, I have restricted the partial
notification mechanism, being used by this package, to be applicable to
a few critical elements only. The new wording opens the door for
additional application-agnostic partial notification mechanism (when
defined) to be used with this package in future.

3. The changes to XML since -09 are:
- <active-media> container removed
- <available-media> container is now indexed by 'label' and contains a
new media <status> element
- <maximum-user-counter> and <user-counter> are overall counters now
(i.e. the <role>-s are removed)
- <endpoint> is indexed by <entity> of type xs:string (i.e. the
secondary index is removed)

With these changes, I am not aware of any issues that prevent this
document from being WG Last Called.

In order to move forward efficiently, when you post your comments,
please, be specific whether it is a requirement issue or it is a
potential technical issue (e.g. the text is not clear, the mechanism
doesn't work, etc.).

Thanks,
Orit.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Mon, 11 Apr 2005 20:54:48 -0500

On Apr 7, 2005, at 9:54 AM, Gonzalo Camarillo wrote:

> addressing comments she received during its WGLC. Nobody has 
> complained since this draft was released (see below).
>
> If anybody thinks that this draft is not ready to be sent to the IESG 
> at this point, please speak now. Otherwise, we will request its 
> publication (together with the other three conferencing documents) on 
> April 14th.

I'd like to point out that there were SUBSTANTIAL changes to the doc to 
address issues raised during WGLC. If you have any interest in the 
topic, you should read the new draft with the same level of intensity 
you would apply to a WGLC.

Thanks,

--
Dean Willis
SIPPING co-chair

---

From: [email-masked]
Date: Wed, 13 Apr 2005 15:07:37 +0200

Hello all
I have a few clarification questions on the usage of RFC 2617 (HTTP-Digest)
in SIP

1) From my understanding, RFC2617 foresees following case where the client
sends a "cnonce" and a "nonce-count" in the "Authorization" header and
where the server uses these values to calculate a "response-digest"
("rspauth") sent in an "Authentication-info" header (e.g. in the sip answer
to a REGISTER method that the remote UA (registrar) or the proxy has
authenticated via an Authorization header sent by the UAC).
On the other hand in situations where the client has got other mechanisms
(certificate in sip over TLS, AUTN network signature  when HTTP-Digest-AKA
applies) to check that it is not in front of a rogue network, it seems that
a  "response-digest" ("rspauth") in an "Authentication-info" header is not
needed

1a)Here comes my question: how does the server know whether or not it MUST
send a  "response-digest" ("rspauth") in an "Authentication-info" header?

1b)Does the fact that the client puts a  "cnonce" and a "nonce-count" in
the "Authorization" header imply that the client expects a
"response-digest" ("rspauth") in an "Authentication-info" header?

1c) Do sip clients usually expect such "response-digest" ("rspauth") in an
"Authentication-info" header?

2) Could someone please clarify or refer to a RFC explaining precisely what
the entity-body should be in the case of sip when the "qop" value is given
the value "auth-int"?
If the "qop" value is "auth-int", then A2 is:     A2       = Method ":"
digest-uri-value ":" H(entity-body)
(Note this is not detailled in the sample C code at the end of RFC2617)

3) When reading RFC 2617 it seems that
      - on one hand next-nonce is mandatory in AuthenticationInfo header as
described in following extract of the RFC
      AuthenticationInfo = "Authentication-Info" ":" auth-info
      auth-info          = 1#(nextnonce | [ message-qop ]
                           | [ response-auth ] | [ cnonce ] | [nonce-count]
)

      - on the other hand it seems optional as described in following
extract of the RFC (2 lines below the former extract)
   The server
   may send the Authentication-Info header with a nextnonce field as a
   means of implementing one-time or otherwise changing  nonces. If the
   nextnonce field is present the client SHOULD use it when constructing
   the Authorization header for its next request.

Could you tell me whether or not at your understanding next-nonce is
mandatory in AuthenticationInfo header.

Thanks in advance for the answers
Best regards
Laurent Thiebaut