Subject: [Sipping] WGLC Summary for draft-ietf-sipping-conference-package-06

From: "Orit Levin" <[email-masked]>
Date: Tue, 23 Nov 2004 13:48:43 -0800

WGLC has ended for draft-ietf-sipping-conference-package-06.

I am planning to incorporate the comments by Miguel Garcia and Cullen
Jennings in the draft.

They will result in the following updates:

   o  Whispers are removed.
   o  The "version-type" is redefined as "unsignedInt".
   o  The "user" elements are grouped in a container named "users".
   o  The attribute "entity" of "media-type" is renamed to "id".
   o  The "media-state-type" is redefined to use SDP values "recvonly",
      "sendonly", "sendrecv", and "inactive".
   o  Sub-elements "snd-state", and "rcv-state" of "media-type" are
      removed.
   o  Sub-element "ssrc" of "media-type" is renamed to "src-id".
   o  The "extended-type" is removed and the standard XML extension
      conventions are used instead.
   o  Descriptive text and editorial nits are added throughout the
document.

   o  The XML elements and attributes are styled in the descriptive text
according to Miguel's suggestions.

I tend to NOT incorporating (unless there is an objection expressed to
it) Miguel's suggestions to:
 
   o  Merge the conf-uris and service-uris under the same element (they
clearly mean different things).
   o  Add the "purpose" element to the "uri-type" and register with IANA
the "purpose" values used with "service-uris" (leave this job to XCON)

No other major issues have been identified.

After resubmitting the draft as
draft-ietf-sipping-conference-package-07, I believe, it will be ready
for the next step in the process.

Best Regards,

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: Miguel Garcia <[email-masked]>
Date: Wed, 24 Nov 2004 17:02:37 +0200

Hi:

Some comments on two of the not-agreed issues:

> clearly mean different things).

I agree that these URIs clearly mean different things, but we have the 
<purpose> element exactly to differentiate their means, so I don't think 
there is a need to do further differentiation into <service-uris> and 
<conf-uris>. This is more a aesthetic issue, since it doesn't have an 
inpact on the functionality.

> the "purpose" values used with "service-uris" (leave this job to XCON)

The <uri-type> will contain the <purpose> element, since this type will 
be used by any kind of URI. So, if I understand correctly, you don't 
want to register with IANA the possible values that will indicate 
additional services (e.g., CPCP, MPCP, ... you name it). If this is the 
case, I have no problem with this approach. We just need to make sure 
that the protocols in XCON (CPCP, MPCP), etc. will register with IANA 
the token in the <purpose> element of the conference event package.

- Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland