Registration of media type "application/nss"

[Mike Hammer]

Scott,

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

Thanks,
Mike

-----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
> 
>