Subject: RE: [Sipping] Proposed revised layout fordraft-ietf-sipping-config-framework

From: "Sumanth Channabasappa" <[email-masked]>
Date: Thu, 9 Nov 2006 12:06:53 -0700

Keith,

Thanks for putting this together. On a quick skim, I think I agree with
most of it (and it seems to flow well), but a few observations/comments
follow:

- Do we need an explicit split indicating 'Profile Notification Server'
and 'Profile Content Indirection Server'? A logical differentiation may
help, but the functionality would be implemented by the same entity
(were you hinting at a logical separation or different entities)?

- Unsure if we need a new section for data sets (Section 7) as they are
not within the scope of this document. So, can we handle this as part of
the data set document? If we feel that we need to have this here, it
would be new work (as you have indicated) 

Thoughts?

- S

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 7:26 AM
To: [email-masked]
Subject: [Sipping] Proposed revised layout
fordraft-ietf-sipping-config-framework

During the breakout session on the config framework we decided that the
existing material in this document was essentially covering the right
material and scope, but that a new structure was needed and then a
rewrite of the text that goes into those sections. 

There is a hope that during this rewrite, much duplicate material will
be removed and the document will become shorter as well as the main goal
of making the document more understandable.

To follow normal RFC drafting rules
To follow guidelines for SIP extensions (RFC 4485) To follow
requirements for defining Event packages (RFC 3265)

Comments are welcome, this is a strawman.

------------------------------------------------------------------------
-------------

Abstract

1	Introduction

2	Terminology

3	Overview

	Much of the information in the existing section 4 seems to be
appropriate to be 
	here. 
	
	Suggest also that the definition of different profile types is
moved here from 
	the event package definition. That then leaves the way forward
for the event 
	package to assign parameters to the different profile types.

3.1	Profile Life Cycle

3.2	Reference model

	This will say that the document describes this in terms of UA
acting as Device, 
	and of a Profile Delivery Server, which consists of two parts:
	*	Profile Notification Server
	*	Profile Content Indirection Server
	Indicate that the Profile Content Indirection Server is optional
to implement

3.3	Profile types and data model

	Include here section 6 and stuff from the event package that is
not event 
	package specific. Leave only the coding in the event package.

4	Use cases

Text from section 5 of the document.

5	Processing Rules

	Place in this section the content indirection requirements.

	Need to clearly distinguish all requirements for profile content
server and 
	profile delivery server.

5.1	Device Behaviour

5.1.1	Profile delivery server discovery

5.1.2	Forming URIs for subscription

	Needs to include content from 7.13

5.1.1.1	Device URIs
5.1.1.2	User URIs
5.1.1.3	Local Network URIs

5.1.3	Enrollment with Profile Server
5.1.4	Notification of Profile Changes
5.1.5	Retrieval of Profile Data

	split to cover from both profile notification server and profile
content 
	indirection server.

5.1.5	Upload of Profile Changes

	only from profile content indirection server

5.2	Profile Notification Server Behaviour

5.2.1	Enrollment with Profile Server

5.2.2	Notification of Profile Changes

5.2.3	Retrieval of Profile Data

5.3	Profile Content Indirection Server Behaviour

5.3.1	Retrieval of Profile Data

5.3.2	Upload of Profile Changes

6	Event Package Definition

	The sub-breakdown here comes from RFC 3265 however the idea of
RFC 
	3265 is not to slavishly follow, but to make sure all the
information is 
	contained. Therefore it is proposed that the examples are moved
out of this 
	level to a later point in the document.
	Remove all text relating to content indirection from the
existing event package 
	definition except for the passing of the URI.

	The idea is that this defines the package, but material relating
to the use of 
	the package goes elsewhere.	

6.1	Event Package Name

6.2	Event Package Parameters

	Move out the profile type introduction to the overview.

6.3	SUBSCRIBE Bodies

6.4	Subscription Duration

6.5	NOTIFY Bodies

6.6	Notifier Processing of SUBSCRIBE Requests

6.7	Notifier Generation of SUBSCRIBE Requests

6.8	Subscriber Processing of NOTIFY Requests

6.9	Handling of Forked Requests

6.10	Rate of Notifications

6.11	State Agents

7	Instructions for Data Set Authors

	Substantially new.

	Data set authors need to register a mime type for their data
set.

8	Examples

	See section 7.12 of existing document.

9	IANA Considerations

9.1	SIP Event Package

9.2	New HTTP Event Header

10	Security Considerations

	Much of the procedural text in here actually needs to go back
into the main 
	text ? where there are already some requirements. The text here
should then 
	refer to that text rather than repeat it.

11	References

11.1	Normative References

11.2	Informative References

------------------------------------------------------------------------
----------

Regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

_______________________________________________
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

_______________________________________________
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