[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Open issue#1: draft-drage-sipping-service-identification(URN usage)
Keith and others
The draft is a mix between a general description of how the P-Preferred
& P-Asserted -Service headers are intended used, registration of an
informal URN to be used as NID for these services and the top-level NSS
"3gpp-service" and "3gpp-application".
The draft clearly express that the P-Preferred & P-Asserted -Service
headers are intended to be used within one administrative domain with
agreed policies for generation, transport and usage of such information;
while a general service identification model is not supported. Somehow
the draft is written for 3GPP, but the headers and the behavior is
described in a general way and examples also cover IPTV and PoC, thus to
my understanding the headers have a broader applicability than 3GPP. Due
to this, I think that the draft would benefit from focusing on the
headers and their descriptions and point that URNs are used without
specifying the details of the URNs.
I do not know the background or the requirements for using an informal
URN in this draft. Due to this, it is hard to comment on whether an
informal URN is useful or not. As informal URNs have few registered
values, it seems that they have limited formal usage. It would be useful
to understand the benefits with this approach, compared to formal
namespaces. It can be noted that two possible users of this draft, 3GPP
and OMA, both have their own namespace, and can populate the P-Preferred
& P-Asserted -Headers with URNs using "3gpp" and "oma" as the NID.
I also think it is a bit unfortunate that the draft has specified the
top-level NSS as "3gpp-service" and "3gpp-application", which is
sufficient for 3GPP, but would lead to a separate draft if e.g. OMA
would like to use the mechanism.
I also notice that it has been commented that allowing e.g. 3gpp as the
NID could lead to allowing the usage of "any URN basically turns the
header field
into a transparent container for any URN, and therefore not necessarily
one that is limited to specifying a service or application. If we allow
any URN I don't know how to specify safeguards that it can only be used
for its allotted purpose." I do not se any difference in having an
informal URN and an formal URN. At some point, the details of the NSS
will be determined by the organization managing the subservice
identifiers. Due to this, I think we must recognise and accept that the
organization assigning the detailed NID will register URNs according to
the intention of the draft. Indicating that organizations may use the
draft outside the intention cannot be used as an argument.
This also partly apply to whether a subservice can address w.x.y as well
as w.x.y.z. This will be up to the organization managing the
subservices, thus I do not think there will be any mandate on
propagating from w.x.y.z to w.x.y to w.x to w for all services.
As the draft clearly point out that the draft is targeted solely within
an administrative domain, as relevant organizations (OMA and 3GPP) have
RFCs specifying their NIDs and have procedures to maintain
URN-registration and finally that the details of the NSS has the same
pros and cons regardless of whether formal or informal URNs are used; I
do not really see any benefit with using an informal namespace.
All this said, it is also clear that 3gpp need a solution for this issue
asap. Consequently I would hope that we can come to a conclusion on this
issue and find a way forward as soon as possible.
br
/atle
-----Original Message-----
From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] On
Behalf Of DRAGE, Keith (Keith)
Sent: 21. oktober 2008 15:42
To: sipping at ietf.org
Subject: [Sipping] Open issue#1:
draft-drage-sipping-service-identification(URN usage)
There were comments received from Salvatore Loreto as follows:
"as maybe you have noticed, a draft asking the registration of a
specific URN namespace for general use bye 3GPP has been submitted
(draft-monrad-sipping-3gpp-urn-namespace-00.txt).
Now, even if the draft is not specific for service identification, but
has a larger applicability, I do think that the Service-identification
draft has to take it in consideration.
In fact, the present version of the drage-sipping-service-identification
draft defines a new registry called "Service-ID/Application-ID Labels",
claiming that creating a new service at the top-level requires a IANA
action.
However the service-identification draft describes a *private extension*
to the SIP that enable a network or trusted SIP servers (like 3GPP) to
assert the service of authenticated users.
So I do really think that these private networks should have the freedom
to define an its own *private* label that define a service, especially
if you consider that this label is thought to be used only within the
private networks.
Really, I don't understand why something that should be used only within
private/trusted network, like 3GPP, should require the usage of a IANA
registered label."
And Atle Monrad as follows:
"On draft-drage-sipping-service-identification-01 I would like to ask
wheter it would be more beneficial to leave out the registration
URN-namespace registration and only point to e.g. RFC 2141.
This would make the draft focusing on the usage of the P-headers, which
I think is fine. The draft would also be flexible and could be used by
other organisations that has their own URN-administration. E.g. OMA
which describes their internal URN-structure in RFC 4358. 3GPP is in the
process of creating a similar draft that can be found as
draft-monrad-sipping-3gpp-urn-namespace.
As the draft-drage-sipping-service-identification-01 currently desribes
the top-level URN for 3GPP ("3gpp-service" and "3gpp-application"),
URN-administration is as I see it needed anyway for the subservice
identifiers and the application identifiers within 3GPP. Further, OMA
will as I understand it need to either update Keiths draft or write an
OMA-specific draft to include the possible "OMA-service" and
"OMA-application" top level URNs. I do not understand the benefit with
having the top-level URNs handled by IANA as IANA anyway subcontract the
URN administration to other SDOs.
By leaving the URN-administration out,
draft-drage-sipping-service-identification would gain flexibility to be
used by other organisations as OMA without any additions. As the draft
mention POC as a "service" in an example, I would also find it useful
that the draft is flexible enough to also cover OMA.
My comments mainly concerns the introduction and the clauses 4.3, 4.4
and 8, and can be taken into account without much rewording and does not
affect the technical content concerning the definition and usage of
P-Preferred-Service and P-Asserted-Service.
I fully understand and support the need to expedite the handling of this
draft due to 3GPP, but I do not think that this comment will slow down
this process, but rather secure that the draft can be completed timely
with the needed flexibility."
Which are currently unresolved.
I would have two responses to this:
1) Allowing the usage of any URN basically turns the header field
into a transparent container for any URN, and therefore not necessarily
one that is limited to specifying a service or application. If we allow
any URN I don't know how to specify safeguards that it can only be used
for its allotted purpose.
2) There are currently capabilities specified in the document on
URNs that are specific to the current one specified. It is unclear how
one would reflect those capabilities when any URN is used. Specifically
these are:
- that if a urn-xxx:w.x.y.z is not understood then urn-xxx:w.x.y
can be used as the service
- that a urn should be able to be an address that resolves to some
location that gives some more information about the service and its
characteristics.
Subsequent discussions in 3GPP have expressed a view of going for an
option which gives the quickest resolution of the draft.
Do people have any comments or wish to express preferences?
Regards
Keith
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
sip-implementors at cs.columbia.edu for questions on current sip Use
sip at ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP