Comments on: draft-drage-sipping-service-identification-01
No. |
Location |
Comment type |
Commentor |
Comment |
Resolution |
1 |
5.1.3 |
NIT |
Ian
Elz |
Section 5.1.3 1st paragraph: "reachs" ->"reaches" |
Fixed |
2 |
2 |
NIT |
Ian
Elz |
Reference [6] I think you mean RFC 3325 in this reference and also where the reference is made Section 2 2nd paragraph. The only comment from my previous list which does not appear in the new version is the correction to the RFC number in Ref 6. This should be 3325. |
Fixed |
3 |
4.1,
5.1.2 |
Context |
Ian
Elz |
In Sections 4.1 and 5.1.2 you mention P-Asserted-Identity. I do not see the context of the reference to these headers in this draft or in the positions in which they are include din the draft. |
Fixed
already in -01 |
4 |
General |
Open
issues |
Ian
Elz |
There are 3 remaining open issues in the draft. I am unsure if these need to be resolved before the draft can reach RFC status. |
Fixed
already in -01 |
5 |
1 |
Open
issues |
Ian
Elz |
OI1 - Introduction - What is a service ? Is a definition of the term service really required in this document. From my reading of the document the intent is to define headers which will enable a service identity to be passed in a SIP Request and to define a structure which will allow registration of the identities of the services. The definition of a service is outside this scope. While the definition of a service is interesting it is not a key aspect of this document. Proposed Text: The definition of the term service is outside the scope of this document. Separate activity is being undertaken to resolve this issue. This document limits its scope to defining the headers necessary to passing of the service identity and the structure for defining the service identities. |
Fixed
already in -01. Reference is made to draft-ietf-sipping-service-identification
as the basis for this. |
6 |
1 |
Open
issues |
Ian
Elz |
OI2 - Introduction - Reference to proposed SIPPING document. Is this reference required. The note above is quite explicit in stating that extension of SIP may be required to allow for identification of a particular service. This fact should be enough. |
Reference
continues – see above for definition of service. |
7 |
4.3 |
Open
issues |
Ian
Elz |
OI3 - Section 4.3 - Service Identifier and Application Identifiers. I am unsure that what is here is actually an issue and it could be rewritten as a statement rather than an issue. Proposed Text: The syntax defined below provides the capability to distinguish between service identifiers and application identifiers. It is currently not clear whether this capability is needed but the ability to use this capability adds flexibility to the definition. If the sole purpose is to identify a particular API within the end terminal, then it may well be that the extensions provided by [11] fulfils this purpose within the genuine usage of a media feature tag. |
No
distinction is now made in the text between services and applications.
Different identifier roots are provided within the URN however. |
8 |
General |
|
Ian
Elz |
There are also a couple of references [xx] where you have the references listed in the document. |
Fixed |
9 |
General |
|
Barry
Leiba (Security directorate) |
I have to say up front that I'm very unhappy with this document. It doesn't say what its status is, but I see from the tracker that it's informational, not standards-track. Still, it seems to provide very little information, and waves its hands about too many things. |
category="info" added to top of
document. |
10 |
1 |
|
Barru
Leiba (Security directorate) |
It also has
enough problems with grammar that I'm often not sure what it's trying to
say. The very first sentence of the
introduction, for example: This document describes private extensions
to the Session Initiation Protocol (SIP) that enable a network of
trusted SIP servers to assert the service and for users entitled to that
service. I can't parse
that sentence, and I don't know what it means to say. Similarly for the beginning of section 4.2: The P-Preferred-Service header field is
used from a user agent to a trusted proxy to carry the preferred
service of the user sending the SIP message wishes to be used for the
P-Asserted-Service field value that the trusted element will insert. It's hard to
decide on the technical content of a document when there are what seem to be
key bits that aren't readable. |
Introduction changed to: "This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service possibly subject to the user being entitled to that service. " 4.2 modified to: " The P-Preferred-Service header field is used from a user agent to a trusted proxy to carry the preferred service of the user sending the SIP request that the user wishes to be used for the P-Asserted-Service field value that the trusted element will insert." |
11 |
General |
|
Barry
Leiba (Security directorate) |
What I *can*
understand seems to be missing a lot.
It seems to me that this document is basically defining two new SIP
header fields, P-Asserted-Service and P-Preferred-Service. The document is very vague -- necessarily
so, it says -- about the actual usage of these fields, and that's the second
thing that makes me unhappy with publishing this. The vagueness results in my not
understanding what it is that these fields are used to assert or request, why
and when a SIP request would want/need to use these (and when it wouldn't),
and what, exactly, happens when they're used.
I can't imagine that an implementor who didn't already know what was
going on would get things right based on reading this document. And my experience with even simple protocol
standards is that there are many implementors who get things wrong even when
the specs are clearly written -- and SIP is not a simple standard. |
TO RESOLVE |
12 |
Security
considerations |
|
Barry
Leiba (Security directorate) |
The third thing
that bothers me is that the Security Considerations section blows off all
considerations, even though there are many references in the document to
security-related issues. Trust domains
are talked about often, and there are MUST and MUST NOT requirements for
passing around information and credentials.
None of that is brought up as a security consideration. For example, here's something, in section
5.1.3, that I think has to be discussed in the security considerations section: If a UA is part of the Trust Domain from
which it received a request containing a P-Asserted-Service header
field, then it can use the value freely but it MUST ensure that it
does not forward the information to any element that is not
part of the Trust Domain. What happens if
it does forward this information? How
does it know what elements are part of the trust domain? Can the composition of the trust domain
change over the life of a SIP request/session? How can a trust domain rely on the actions
of a user agent? What if a malicious
user tampers with the user agent, which is, after all, under his
control? How does the trust domain
defend itself against that? Why are
security-sensitive itens entrusted to a user agent in the first place? There may be
reasonable answers to these sorts of questions, but there's nothing at all
about them in the security considerations. All in all, I
think this document needs significant work before it's ready to be published. |
Following paragraph added to service considerations: "The trust domain provides a set of
servers where the characteristics of the service are agreed for that service
identifier value, and that the calling user is entitled to use that service.
draft-ietf-sipping-service-identification <xref
target="I-D.draft-ietf-sipping-service-identification" />
identifies the impact of allowing such service identifier values to
"leak" outside of the trust domain, including implications on
fraud, interoperability and stifling of service innovation." |
13 |
General |
|
Salvatore
Loreto |
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. |
Ted Hardie commented: > I'm a wee
bit confused by your comments here.
Can you clarify what > the 3gpp
NID proposal does here that worries you?
Organizational > namespaces
aren't exactly rare in the URN registry:
iso, oma even xsf. > 3gpp looks
to be asking for a very general entry of the same type, at > least if
I'm reading the namespace considerations correctly. Salvatore Loreto responded: I am totally in
favor of a 3gpp NID proposal. in fact I am
just asking Keith to modify the service-identification draft and let possible
the usage of Organizational namespace. At present in the
Keith draft *creating a new service at the top-level requires a IANA
registration*. NOT RESOLVED |
14 |
General |
|
Eric
Burger |
The mechanisms
described in the draft for the P-Asserted-Service makes sense and is
useful. My only comment with
P-Asserted-Service is I would STRONGLY RECOMMEND an IESG note on the cover of
the draft warning of the dire consequences of relying on the
P-Asserted-Service between administrative domains or between a SIP User Agent
Client and the network. However, the
mechanisms described in the draft for P-Preferred-Service have no utility
and, in fact, may result in harmful behavior. To wit,
consider the following section from the draft: 5.1.1. Procedures at User Agent Clients
(UAC) The UAC MAY insert a P-Preferred-Service
in a request that creates a dialog, or a request outside of a
dialog. This information can assist the proxies in identifying
appropriate service capabilities to apply to the call. This information MUST NOT conflict with
other SIP or SDP information included in the
request. Furthermore, the SIP or SDP information needed to signal
functionality of this service MUST be present. Thus if a service requires a video
component, then the SDP has to include the media line
associated with that video component; it cannot be assumed from the
P-Preferred-Service header field value. Similarly if the service
requires particular SIP functionality for which a SIP extension
and a Require header field value is defined, then the request has to include
that SIP signalling as well as the P-Preferred-Service header
field value. What this says
is all of the information required to route the call (i.e., determine the
service) is contained in the INVITE message.
Stated differently, the P-Preferred-Service header PROVIDES NO USEFUL
INFORMATION. To date, in
discussions in the SIPPING Work Group, there have been virtually no service
examples for which the P-Preferred-Service header adds any information. In fact, the examples for which the
P-Preferred-Service header added value highlight why this header will be
detrimental to the Internet. Namely, the use
cases where it does add information are cases where the SIP protocol itself
is deficient. What makes this
use detrimental is the P-Preferred-Service approach is, by definition,
proprietary and non-interoperable.
Rather than repairing or extending the base protocol, this header will
encourage "quick fixes" that do not address the underlying problem. At that point the P-Preferred-Service takes
on protocol meaning, EVEN OUTSIDE A LIMITED DOMAIN. The problem is this protocol meaning is
proprietary and by definition non-interoperable. Moreover, the draft presents no negotiation
mechanism, nor do I see how there could possibly be a negotiation mechanism. Standard SIP
user agents and proxies will not be able to negotiate common communication
parameters if a key protocol element is proprietary. Moreover, use
of the P-Preferred-Service in this manner will encourage proxies and user
agents to not bother to parse and interpret the existing information
contained in the SIP INVITE. At this
point, the protocol is no longer SIP. To reiterate, I
have no problem with the publication of P-Asserted-Service, as defined in the
above named draft, as an IETF-reviewed publication. However, I
would strongly object to the publication of P-Preferred-Service as an IETF
reviewed publication. It presents a
clear and present danger to the Internet, and could potentially end the
possibility of having interoperable communications in the Internet. Tim Dwight posted: Apparently you
feel strongly about this, but I don't understand what you're saying. I thought I'd try and clarify what I'm
missing, before posting to the list and being "repeatedly
educated". First
with respect to the mechanisms defined in 5.1.1 which you say "have no
utility and, in fact, may result in harmful behavior." You indicate
that "What this says is all of the information required to route the
call (i.e., determine the service) is contained in the INVITE message. Stated differently, the P-Preferred-Service
header PROVIDES NO USEFUL INFORMATION." Questions: 1) is
"routing the call" synomymous with "determining the
service"? Consider an
analogy with diffserv. The DSCP does
not affect the routing of the packet but it may influence the way the packet
is handled by the routers traversed (i.e., the "service" provided
at L3, to the packet). Hence it seems
there is precedent for separating service and routing. Moreover the
interpretation of DSCP (mapping to PHB etc.,) is defined only within an
administrative domain, which some might call "proprietary and non
interoperable". Yet we accept it,
we've deployed it, the Internet didn't break.
Why was it OK in that case to distinguish service from routing, and
define service such that its meaning may be different in different
administrative domains, but not OK in this case? Or is that a
misunderstanding on my part, of what P-Preferred-Service is meant to achieve? 2) You seem to
be arguing that P-Preferred-Service can only be a summarization of
information that must be elsewhere in the packet. I don't read it that way. I read it to say that P-Preferred-Service
cannot contradict information elsewhere in the packet, nor can it be used
instead of information for which a standard representation is defined. But I don't understand this to mean that
P-Preferred-Service cannot provide additional information. An example. Suppose Verizon offers an "enhanced call screening" service to its VoIP subscribers. Suppose that the network's implementation of this service involves invocation of a collection of functions spread over a collection of application servers. A straight forward way to implement this (within the 3GPP/IMS context, which is I assume the context to which this whole discussion applies) would be to configure the subscriber's UAC (if we control it) or his outbound proxy / P-CSCF, to insert something like P-Preferred-Service=ecs@verizon.com. We could then define filter criteria at the S-CSCF, to cause the "enhanced call screening" service to be invoked (i.e., cause the associated applications to be invoked in some pre-defined manner) based on the presence and of and value contained in this header. Seems pretty straight-forward to me. Can you help me understand (a) what would be a BETTER way to implement this (within the 3GPP/IMS context - which would seem to preclude the obvious alternative of setting R-URI to ecs@verizon.com), and (b) why implementing it as I describe, is so threatening to the Internet? Eric Burger posted: Remember that
in SIP, treatment equals routing. If
one routes based on P-Preferred-Service, it means it is a routing data
element. Let's consider
an example of an abstract service you could offer your subscribers. I will then later discuss the enhanced call
screening scenario you mention below. Let us say this
is a service that is associated with the Verizon subscriber. When the
Verizon subscriber places a call, the subscriber wishes the network to
execute this subscribed service.
Moreover, the service is "hidden," so the Request-URI is
(I'll argue incorrectly used, but let us ignore that for a moment) the
ultimate target, not the actual target (the application server Request-URI
representing the subscribed service). Unless the goal
is to have the user use one and only one device ever, I would offer your
thought of having the P-SCSF do the work is the right thing. Moreover, if the P-SCSF computes a service,
it will be computing a P-Asserted-Service, as the P-SCSF is doing the
asserting. This is one of the uses of
P-Asserted-Service. Moreover, if
your proprietary device is smart enough to insert a P-Asserted-Service
header, it is smart enough to rewrite the Request-URI to point to the real
Request-URI and populate the parameters or however else you define the
application to properly route and handle the call. No need for proprietary P-Asserted-Service
values, and it even gets to route to wherever it needs to go. You get to support service bureaux for
free, without having to re-write your IMS core. As the document
says, P-Asserted-Service will not route across administrative domains, which
is the behavior you want, anyway.
Moreover, the right treatment will happen when the request gets to the
Verizon network, which is ALSO what you want to have happen. It is highly likely for a foreign network
to strip the P-Preferred-Serivce, in which case the service will fail. If you do the P-Asserted-Service
calculation at the P-SCSF, which, by the way, should be dipping the HSS to
verify the subscriber should have access to the preferred service
anyway. Otherwise, why bother with a
P-SCSF? Said differently, having the
P-SCSF determine the service IS EXACTLY THE SAME NETWORK TRAFFIC AND CPU
USAGE as having the client indicate a preferred service. Better yet, there is no opportunity for
fraud, mistakes, and upgrades can happen in a centralized fashion, instead of
having to upgrade all of your proprietary clients. In
this example, the damage to the Internet of using P-Preferred-Service is the
protocol is no longer SIP. Rather than
routing to the requested Request-URI, the protocol is subverted to route
based on P-Preferred-Service. SIP does
not work that way. Moreover, the
temptation becomes to do all routing based on P-Preferred-Service, at which
point why bother with all of the overhead of SIP Tim
Dwight: Thanks for the
reply. The exchange has helped me a
lot. Here's where I've got to in my
own thinking, with your kind assistance: - I am
unconvinced that I have any need for / use for, P-Asserted-Service. - The usage I
see for P-Preferred-Service is to "influence" the service that is invoked through the normal service
selection mechanism. In other words,
however that works, I don't want
P-Preferred-Service to change its result. But I would like to be able to "pass a
parameter to" the resulting service, to cause it to behave differently. I see this as potentially useful, when the function I'm trying to invoke is not
implemented in a separate application server but rather exists as
"conditional code" within an application server. I offer the example of a "QoS
monitor" function, below. That is of some use even if it can't be
passed across network boundaries, but would be more useful if it could. Any chance of changing the encoding to allow this? I accept that that usage may not be
intuitive given the header name we've selected
"P-Preferred-Service". Maybe
what I'm imagining is really some 3rd thing, not P-Asserted-Service and not
P-Preferred-Service. If it's a useful thing (I'm of course interested in
your views there) maybe it could be advanced on its own. More
commentary is inserted inline, below. I don't know
what "treatment equals routing" means. I also don't know that I (or anyone) wants
to route (in the sense of determining an inter-network-element path) based on
P-Preferred-Service. I guess any
parameter whose value is evaluated could be said to "dispatch" the
associated logic, and therefore be said to be a routing data element - the
result being that virtually all parameters are so categorized. I suspect there's something I'm missing
here. Given the
common use of retargetting, you sorta have to say _where_ (at what interface)
you're talking about. It doesn't
strike me as wrong that the R-URI inserted by the originating UE would be as
you describe; in IMS that would be common.
In pre-IMS networks (at least the ones we've built) the UE is
configured to populate R-URI with the FQDN of the AS instance at which the
subscriber's service data is provisioned.
The latter seems to be what you're regarding as correct. I would argue that either can be correct
depending on context. My notion was
to insert a provisioned value that is meaningful in the subscriber's home
network, but not otherwise standardized.
I don't think that would be an appropriate usage of
P-Asserted-Service. I can think of
examples where it's best that the UE insert it (e.g., where its value is
based on the context in which the request is made) and examples where it's
best that the P-CSCF insert it (e.g., if its effect is to invoke a capability
in the network that the subscriber wouldn't voluntarily request, wouldn't be
allowed to request, wouldn't understand, etc.,). An example of the latter might be a
"QoS monitor" that we could
invoke on behalf of subscribers who report service problems, or use for
statistical sampling of network performance. You assume that
there is a "real Request-URI" that can in all cases be used to
convey the desired network behavior. I
don't know that that's the case. In
the "QoS Monitor" example above, I don't want the message to be
routed any differently than it normally would be. I only want to invoke some additional logic
within the application servers that normally process this type of call. It's possible that not all of them have
such logic; in which case I would want them to ignore P-Preferred-Service. I'm unconvinced
that I have any use for P-Asserted-Service.
It would be helpful for P-Preferred-Service to be carried across
administrative domains, ignored where not understood. I'm not sure the proposed URN coding is
adequate - seems like a URI would be better in this respect. If the host
part identified a domain for which the entity that owns the device examining
the header is not authoritative, the value would be ignored. That would be
nice :-) In the examples
I have in mind, the service wouldn't fail but the "extra function"
I intended to trigger by including P-Preferred-Service, wouldn't get
triggered. Which is unfortunate, and
if there were a way to make it work in roaming scenarios I'd certainly prefer
that. The P-CSCF does
not interface to the HSS. But anyway I
have no interest in P-CSCF "calculating" P-Asserted-Service, nor
any use for P-Asserted-Service generally. I don't see
much value in any element "calculating the service". This whole concept is useless in IMS, where
determination of the service must involve access to / evaluation of, filter
criteria. At this point,
the only thing of value I see here is the ability to insert via the P-Preferred-Service
header a value that can "influence" the service, as
illustrated in the "QoS Monitor" example above. Maybe in
someone else's preferred usage that is the case. Not in mine. That question
does come up a lot... H.323 is looking better all the time :-) That's
interesting but not what I had in mind.
I meant something a lot simpler - e.g., to block access to certain
numbers. Imagine a parent who wants
their home phone not to have access to 900 numbers while the kids are at home
unsupervised. That sort of thing. To be honest I didn't think deeply about
this. If I had a great new service
idea I would probably not describe it here anyway :-) I don't know
that the term "enhanced call screening" has a standard
meaning. If it does, and I've used it
incorrectly, my apologies. Yes, an
outbound screening service was what I had in mind. Eric
Burger: No worries. The QoS
monitoring tag is *precisely* why P-Preferred-Service is not the way to
go. What you would like is an
indicator for network elements that may understand the indicator to make QoS
measurements, and possibly report on them. That is not
P-Preferred-Service. That would be
something like "record-qos: true" or
"record-qos: https://deepinthenetwork.verizon.net/customer?uname=dtw%2averizon.com&callid =a8923084zzq" It would be
useful to standardize that function, so multiple, interoperable
implementations could be done so service providers could buy standard
equipment, instead of proprietary, network-specific implementations. Moreover, what
happens when one has another useful thing that wants to use
P-Preferred-Service? Lastly, would
you not want this to have the same meaning to all parties, not just in the
Verizon network? When the Verizon
subscriber calls customer service because of poor quality results, it will
not make them happy to hear, "Well, we know it is not Verizon." It is much more believeable to say,
"We know it is not Verizon, and there are problems identified in the Cox
network." Said
differently, as you point out, this may very well want a new header. Do not make
that header P-Preferred-Service. For arguments
sake, let us say that to indicate QoS monitoring, it takes two SIP headers
and three SDP parameters, all taken together to mean "monitor this
dialog." This is the
justification for P-Asserted-Service.
Rather than have every network element parse the entire INVITE and
calculate whether or not to do QoS monitoring, you can have your ingress
point do the calculation once and then insert the P-Asserted-Service
header. That way the other network
elements do not need to do the calculation, greatly increasing the scale of
your core network processing capability. On the call blocking
example, we are again using the wrong tool.
There are two places to block the calls, in the user equipment or in
the network. The P-Preferred-Service
proposal does neither. If the handset
is smart enough to insert "P-Preferred-Service: Block-900", it is
smart enough to simply block 900# calls.
The problem is, that feature is device specific. Trust me, it would take a 14-year-old about
15 minutes to figure that out. Thus, what you
want is a network-based service.
Moreover, you want a network-based service that works will all of the
subscriber's devices, now and into the future, NOT a particular piece of
equipment or terminal adapter (too easy to circumvent). This is a
classic case for a B2BUA. Most often,
this would be a P-SCSF (SBC), but could be service logic executed at the
S-SCSF or SCIM. The point is one wants
the service logic applied to all requests by the user, not by all requests
from a particular device. Again, this
highlights the danger of P-Asserted-Service.
While it looks like it might work for the call blocking case, it turns
out it does not work at all. Looking at some
of the comments below, it looks like what we really want is some way to pass
parameters from end-to-end, the second end being the application
server(s). That would not be
P-Preferred-Service, as that would have serious name collision potential as
the draft is now written. However,
such a facility would be hugely useful.
I would have loved to have such a facility for RFC 4240, for
example. That may be even more work
worth doing. Keith: two more
work items? :-) Tim Dwight: Maybe so, for
someone else's definition of this capability.
For mine, I'm only hoping to communicate to the application
server(s). It's possible that this
example is so universal that the indicator used to invoke it should be
standardized. No problem. But it's also possible that this (or other)
capabilities are less universal, and most expedient to support on a
network-specific basis. Certainly I
think it would hinder innovation if every parameter one wished to pass to an
application server had to be standardized. We all like it
both ways :-) We like and benefit from
standardization, but also seek ways to differentiate. Seems to me
this is a coding issue. We could allow
multiple instances of the header, or allow the header to communicate multiple
values. I think the more interesting
question is how we avoid collision between (a) networks
and (b) applications within a network. In the example
I cited, the application whose behavior was to be influenced by the value
encoded in P-Preferred-Service, is in the home network. I am not
opposed to a standardized "record-qos" type header, as you suggest
above. Practically speaking I think it
would be hard to convince operators to share network impairment
information. In the end we'd probably
benefit, but it's not in our nature :-)
But anyway that's a different capability I understand
the theory but am unconvinced by the examples. If we have designed the signaling such that
these 5 parameters jointly mean one thing, and don't individually have any
other purpose, then we've designed it badly.
We should just signal the one thing.
The more likely case is that they do have individual meanings, or
meanings when grouped with other parameters, and for that reason they'd have
to be evaluated whether or not P-Asserted-Service is present. Yep, in that
case the parameter would need to be inserted by the network on behalf of the
user. That's not the only use case for
the capability I have in mind ("tunneling" a parameter to an app
server to influence its behavior), though maybe it's the dominant one in
practice. I wouldn't want to preclude
that the UE inserts the parameter, because there might be interactions
between the application initiating the session request and the application
server in the network, that devices downstream of the UE wouldn't know. I agree that
were this capability one we're imposing on the customer we'd want to do it in
a device to which he has no access, but not all capabilities we might like to
support fall in that category. For
some conceivable usages, the invocation *has* to come from the UE, because no
device other than the UE knows what value to assert. Sometimes. Depends on what the service logic is. I wouldn't rule out that it could be device
or end-user-application -specific. Yes. Sign me up :-) |
Added the following text to the introduction: " This document also makes use of the terms "derived service identification" and "declarative service identification" as defined in draft-ietf-sipping-service-identification <xref target="I-D.draft-ietf-sipping-service-identification" />. And the following text to the definition of P-Asserted-Service: " The P-Asserted-Service header field carries information that is derived service identification. While a declarative service identification can assist in deriving the value transferred in this header, this should be in the form of streamlining the correct derived service identification." And the following text to the definition of P-Preferred-Service: " The P-Preferred-Service header field carries information that is declarative service identification. Such information should only be used to assist in deriving a derived service identification at the recipient entity.
" DO WE NEED FURTHER RESOLUTION |
15 |
General |
|
Atle
Monrad |
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. |
NOT RESOLVED |
16 |
|
|
Christer
Holmberg |
The draft now
says that the ABNF can be used both for services and applications, which is
good. However, the
ABNF still contains the '*("-"application-id)' part, which I don't
think is needed. |
Fixed. |
17 |
|
|
Christer
Holmberg |
One of the
issues below we discussed in First, I think
the *("-"application-id) part of the ABNF shall be removed (since
the URN itself can be an application id), and my understanding from Second, chapter
8.2 now defines "3gpp-service" and "3gpp-application". However, the
ABNF does not allow the "-" character for top-level, so that needs
to be changed. So: let-dig = ALPHA / DIGIT ...should be
something like: let-dig = ALPHA / DIGIT / "-" |
Fixed as proposed. |
18 |
|
|
Christer
Holmberg |
And a third
issue. The ABNF says: Service-ID = "urn:xxx:" urn-service-id But, I think
the agreed correct syntax shall be: Service-ID = "urn:xxx." urn-service-id ...ie a DOT
after "xxx", instead of Forget my third
issue. It shall be "xxx:" |
Withdrawn by commentor |
19 |
|
|
Christer
Holmberg |
A new third
issue: The ABNF says: "urn:xxx:" But, according
to RFC 3406 the informal NID shall have a "urn-xxx" format. So, the correct
syntax should be: "urn:urn-xxx:" ...which is
also the value used in the 3GPP specifications. |
Fixed |
20 |
|
|
Ian
Sharp |
Just a short note to let you know this reference is wrong in your draft. [6] The RFC number should be RFC 3325. |
Fixed |