RE: Last Call: draft-drage-sipping-service-identification (A Session Initiation Protocol (SIP) Extension for the Identification of Services) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



All

Due to lack of response, and as my 1st mail had a different Subject-line
thus may have been missed by mistake, I resubmit the comments. Sorry for
any inconvenience.

-------

On draft-drage-sipping-service-identification-01 I would like to ask
wheter it would be more beneficial to leave out the 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. 


Thanks

Atle Monrad
Chairman 3GPP CT1

 
-----Original Message-----

The IESG has received a request from an individual submitter to consider
the following document:

- 'A Session Initiation Protocol (SIP) Extension for the Identification 
   of Services '
   <draft-drage-sipping-service-identification-00.txt> as an
Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf at ietf.org mailing lists by 2007-08-06. Exceptionally, 
comments may be sent to iesg at ietf.org instead. In either case, please

retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-drage-sipping-service-identifi
cation-00.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
15991&rfc_flag=0


_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce





_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]