Subject: [Sipping] seeking comments on draft-haluska-sipping-directory-assistance-01.txt

From: "Haluska, John J" <[email-masked]>
Date: Tue, 9 Jan 2007 10:55:18 -0500

Hello all, 

I am seeking comments on
draft-haluska-sipping-directory-assistance-01.txt. Specifically,

1. Assuming that the providers involved agree, does it seem reasonable
to specify the use of the domain-name format of P-Asserted-Identity, in
order to determine the identity of the home provider? This seems to make
sense, especially given the fact that SBCs can break SIP Identity, as
pointed out in the recent identity coexistence draft.

2. Does it seem reasonable to maintain a list of values for "via"
headers expected from providers from which the Operator and Information
Services Provider (OISP)  would expect to receive calls, to identify the
provider who is sending the call to the OISP? These would be providers
with whom the OISP has a pre existing relationship.

3. For identifying the caller's terminal capabilities and
characteristics, we plan to specify  the use of RFC 3840 (indicating UA
capabilities in SIP) when it is supported - it is not in the current
revision of the draft. Where it is not supported, the session either
needs to do without this information, or some lookup (e.g. HSS in am IMS
environment) could be done.

4. We plan to reduce the scope - it will not normatively define an
architecture (it will still describe one for the purposes of discussion)
and concentrate more on identifying existing SIP mechanisms for
conveying the required information, and will include additional call
flows. 

Any comments are greatly appreciated.

Thanks

John Haluska

_______________________________________________
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: [email-masked]
Date: Tue, 9 Jan 2007 18:06:51 -0500

From: "Haluska, John J" <[email-masked]>

   I am seeking comments on
   draft-haluska-sipping-directory-assistance-01.txt.

I'm mystified by what this draft is trying to accomplish.  If a SIP
user wishes to contact an Information Service, he can just issue an
INVITE to the service's URI.  This draft seems to assume that all
information services are integrated into the fabric of the transport
network, which is a poor architectural decision with adverse economic
consequences.

At the very least, you can correct the first sentence of the abstract:

   Information Services are services whereby information is provided by 
   the network in response to user requests

By definition, a network doesn't *provide* information, it
*transports* it.  Network endpoints provide information.

OK, I'm being cranky here.  But if all this apparatus is necessary,
there must be some requirements that I don't see stated clearly.

Dale