Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to 'hint'?)

From: [email-masked]
Date: Wed, 5 Jun 2002 08:08:49 -0400

Roy, Radhika R, ALASO writes:

 > [RRR] The architecture for the 3GPP application server environment can
 > also be applicable in any wire-line network. So, the P-headers defined
 > for 3GPP may have the wider applicability.

juha> i prefer an open internet style architecture instead of the 
recreation
juha> of the closed pstn architecture using ip protocols.

Im sure a lot of us would have personal preferences on the right way. 
Right now the industry
is struggling to figure out how to make money out of SIP - which is a more 
realistic step towards
making SIP successful than asserting that sip is a great 
internet-style-peer-peer-protocol.

Therefore no matter how 'pstn like' 3g in architecture (and I see nothing 
wrong with that - again a personal 
perspective - the centralized model allows a definitive path to revenue), 
I would agree that its a good
thing.

However, I would agree with radhika here:

The concept of P-headers is OK to me - but as mentioned, we _dont_ have to 
tie it to 3G. P-headers
may be viable in 3G as well as other networks as well - thefore , the 
scope of P- headers would 
be for 'networks with certain mandatory properties'. If 3G falls into it, 
fine. If some other networks
fall into it - fine as well - it was not meant only for 3G anyway.

regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-475-2139

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

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Wed, 5 Jun 2002 16:24:28 -0400

inline [RRR]

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 11:40 AM
nt'?)

Juha writes:

> i prefer an open internet style architecture instead of the 
> recreation of the closed pstn architecture using ip protocols.

100% agreement. 

Henry

[RRR] Agreed, it should be the long term goal as it is the only way to
make the system scalable in the context of the open Internet.

>  > [RRR] The architecture for the 3GPP application server 
> environment can  > also be applicable in any wire-line 
> network. So, the P-headers defined  > for 3GPP may have the 
> wider applicability.
> 
> i prefer an open internet style architecture instead of the 
> recreation of the closed pstn architecture using ip protocols.
> 
> -- juha
>

---

From: David Oliver <[email-masked]>
Date: Thu, 6 Jun 2002 11:03:24 -0500

It seems that the problem with P-Headers is that they are overloaded to mean
both Private/Proprietary and Preliminary/Pre-Standards-Track. These are both
distinct from strictly experimental (X?) headers in that they are published.

In the Private case, publication is informational to the Internet community
at large and serves to reserve the name, provides assistance in
understanding third party traffic, and may avoid reinventing the wheel for
similar applications. Applicability is "restricted", but that could mean
"only applicable to POTS, ISDN and Mobile PSTN applications"!

In the Preliminary case, the header is believed to have unrestricted
applicability, and is urgently required, but the proposal is insufficiently
solid to qualify for Standards Track. This could mean that only one
community's requirements have been reviewed, or that there are known (but
unresolved) technical limitations or risks. Publication reserves the name
(and possibly reserves the non-P name?), and provides a suggested mechanism
for early adopters, with the caveat that changes are likely.

Preliminary headers should either be reviewed, adapted as necessary, and
adopted as full Standards Track headers, or rejected and moved to Private
status. A time limit should be imposed on this process to avoid them staying
in limbo indefinitely.

Separating out these overloaded uses of P Headers into two distinct
namespaces could help - or at least move the controversy into a better
defined arena.

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: [email-masked]
<mailto:[email-masked]> Tel:    210.402.9669
Fax:   210.402.6996 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 2:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: SIP Change Process (was RE: [Sip] Asserted-Identity: How to
'hint'?)

> once ietf defines a p header for some purpose, there is far 
> less motivation to produce the corresponding standards track 
> sip header. the result is weaker sip and non-interoperable products.

That is a legitimate position to take regarding the proposed SIP Change
Process, something that we ARE working to refine.

...

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 7 Jun 2002 13:38:30 +0100

At the end of the day it does not matter what these headers are called, or whether they appear in information or standards track RFCs, people will implement and use the ones they find useful, and ignore the ones that they do not. It is not standards organisations that make standards, it is the number of interoperable implementations.

Therefore at best the name of the header (i.e. P-...) can only be an extremely rough guide as to whether it is useful or not.

Based on this:

-	I do not believe we should do any more to fragment the naming options that exist, by subdividing categories.
-	If a P-header appears to be more generally useful, I do not believe we should rename it. I guess I have no problem with turning the document it was specified in from informational to standards track, but it seems unnecessary and after the event to do so.

Keith

> From: David Oliver [mailto:[email-masked]]
> Sent: 06 June 2002 17:03
> To: 'Dean Willis'; [email-masked]
> Cc: [email-masked]
> Subject: RE: SIP Change Process (was RE: [Sip] 
> Asserted-Identity: How to
> 'hint'?)
> 
>

---

From: David Oliver <[email-masked]>
Date: Fri, 7 Jun 2002 13:29:28 -0500

Keith,

Personally, I tend to agree with you, but people seem to be concerned that
P-headers are both too weak (not standardized) and too strong (a back door
way to get something standardized). This may be partly related to the
differences between the Internet and ITU/PSTN standards processes (I recall
overhearing at one TIA/EIA meeting that only documents from government
approved bodies can be standards).

The right answer is probably education, combined with better language in
documents explaining why they are using P-Headers, rather than going
straight for full headers.

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: [email-masked]
<mailto:[email-masked]>
Tel:    210.402.9669
Fax:   210.402.6996 

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]]
Sent: Friday, June 07, 2002 7:39 AM
To: David Oliver; 'Dean Willis'; [email-masked]
Cc: [email-masked]
Subject: RE: SIP Change Process (was RE: [Sip] Asserted-Identity: How to
'hint'?)

At the end of the day it does not matter what these headers are called, or
whether they appear in information or standards track RFCs, people will
implement and use the ones they find useful, and ignore the ones that they
do not. It is not standards organisations that make standards, it is the
number of interoperable implementations.

Therefore at best the name of the header (i.e. P-...) can only be an
extremely rough guide as to whether it is useful or not.

Based on this:

-	I do not believe we should do any more to fragment the naming
options that exist, by subdividing categories.
-	If a P-header appears to be more generally useful, I do not believe
we should rename it. I guess I have no problem with turning the document it
was specified in from informational to standards track, but it seems
unnecessary and after the event to do so.

Keith

<...>