Registration of media type "application/nss"

[Scott Hollenbeck]

Forwarding a link to the published specification for the request described
below:

http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-Q
.1980.1

Note that it's not available without paying a fee.

-Scott-

> -----Original Message-----
> From: Scott Hollenbeck [mailto:sah at 428cobrajet.net] 
> Sent: Thursday, December 30, 2004 7:59 PM
> To: 'Mike Hammer'; iesg at ietf.org
> Cc: ietf-types at iana.org; iana at iana.org
> Subject: RE: Registration of media type "application/nss"
> 
> Mike,
> 
> Request received.  I will shepherd your request once the 
> ietf-types review has been completed and any comments have 
> been addressed.  Please contact me directly at the end of the 
> two-week review period and we'll go from there.
> 
> Can you provide a link to the published specification 
> referenced below?
> 
> -Scott-
> 
> > -----Original Message-----
> > From: Mike Hammer [mailto:mhammer at cisco.com]
> > Sent: Thursday, December 30, 2004 1:52 PM
> > To: iesg at ietf.org
> > Cc: ietf-types at iana.org; iana at iana.org
> > Subject: Registration of media type "application/nss"
> > 
> > This email requests that the IESG approve the assignment of 
> the media 
> > subtype as described in the registration template below.
> > 
> > Reference:  draft-freed-media-type-reg-01.txt, August 17, 2004,
> >             Media Type Specifications and Registration Procedures, 
> >             Section 5, Registration Procedures,
> >             Section 10, Registration Template.
> > 
> > To: ietf-types at iana.org
> > Subject: Registration of media type "application/nss"
> > 
> > Type name: application
> > 
> > Subtype name: nss
> > 
> > Required parameters: none
> > 
> > Optional parameters: charset
> > 
> > Encoding considerations: binary (Note:  Data is in US-ASCII range.)
> > 
> > Restrictions on usage: none
> > 
> > Security considerations: 
> > 
> >    NSS has the potential to disclose private customer information
> >    and the potential for modification of NSS bodies during message
> >    transport to manipulate call setup, mid-call events, or call 
> >    release.  Modification means the addition of an NSS body where
> >    none existed, the removal of an NSS body where one existed, or 
> >    the changing of contents of existing NSS bodies in messages.   
> >    NSS can reveal information about telephone subscribers that is 
> >    requested to remain private.  Security mechanisms must be 
> >    provided to meet privacy agreements and regulations.  
> > 
> >    NSS can be deployed as an interdomain signaling mechanism and 
> >    may be subject to trust relationships and agreements between 
> >    administrative domains as well as legal requirements in various 
> >    jurisdictions.  NSS can affect routing of telephone calls and 
> >    associated billing.  Security mechanisms must be provided to 
> >    control fraud, malicious intents, and unintended consequences.
> >    Such mechanisms include the ability to selectively filter or map
> >    and forward each information element within NSS upon 
> entry or exit
> >    of an administrative domain.  All information from 
> unauthenticated
> >    entities must be validated and authorized before being 
> mapped and 
> >    forwarded in subsequent signaling messages.  Such checks are 
> >    particularly needed when information is mapped to/from 
> SIP headers.
> > 
> >    When encapsulated by SIP, the integrity and 
> confidentiality of SIP 
> >    messages containing NSS bodies MUST be addressed through 
> the use of
> >    Transport Layer Security (TLS) or Internet Protocol Security 
> > (IPSEC)
> >    mechanisms as described in the Session Initiation 
> Protocol RFC 3261
> >    on signaling hops between nodes trusted to handle PSTN 
> signaling.  
> >    When intermediate hops are not trusted, end-to-end integrity and 
> >    confidentiality may be addressed using RFC 2633, 
> > "Secure/Multipurpose
> >    Internet Mail Extensions (S/MIME) Version 3 Message 
> Specification",
> >    June 1999.  NSS MIME bodies SHOULD be secured using S/MIME to 
> > mitigate
> >    concerns with authentication of the sender, integrity protection 
> >    during transit, and confidentiality protection from 
> disclosure to 
> >    unauthorized third parties.  NSS endpoints MUST support S/MIME 
> >    signatures and SHOULD support S/MIME encryption.  
> > 
> >    For H.323-based encapsulation of NSS bodies, the security 
> > mechanisms
> >    of ITU-T Recommendation H.235, "Security and encryption for 
> > H-series
> >    (H.323 and other H.245-based) multimedia terminals", 
> August 2003, 
> > must
> >    be used to provide integrity and confidentiality.
> > 
> >    NSS consists of well defined message types and parameters. 
> >  Arbitrary 
> >    content or directives within field values is not permitted.
> > 
> >    NSS does not employ "active content."
> > 
> >    NSS contains fields which instruct whether privacy data such as 
> >    calling party's number is to be presented or restricted.
> > 
> >    NSS is used without and is silent about compression.  Use of 
> > compression
> >    in conjunction with NSS does not present any security issues.
> > 
> > Interoperability considerations:  Compatibility mechanisms are 
> >    defined in Q.1980.1.
> > 
> > Published specification:  ITU-T Recommendation Q.1980.1, "The 
> > Narrowband
> >    Signalling Syntax (NSS) - Syntax Definition", December 2004.
> > 
> > Applications which use this media type:  Applications in PSTN
> >    Gateways and call control application servers.
> > 
> > Additional Information:
> > 
> >    Magic numbers:  None
> > 
> >    File Extensions:  None
> > 
> >    Macintosh File Type Codes:  None
> > 
> >    Object Identifiers:  {itu-t(0) recommendation(0) q(17) 1980 1}
> >                         (0.0.17.1980.1)
> >       See ITU-T Recommendation H.323 Annex M.4 "Tunnelling of 
> >       Narrowband Signalling Syntax (NSS) for H.323", December 2004.
> > 
> >    Intended Usage:  COMMON
> > 
> > Person to contact for further information:
> > 
> >    Name:  Michael Hammer
> >    E-Mail:  mhammer at cisco.com
> >    Author/Change controller:  ITU-T Study Group 11
> > 
> > END
> > 
> > 
> 
>