Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan 3 16:22:55 2006

On 1/30/2005 11:24 AM, Bruce Lilly wrote:

> 2. An IANA Considerations section related to establishment of a
>    format value keyword registry (containing the "default" entry),
>    and maintenance of that registry in conjunction with the
>    registration procedure.

Yeah probably.

> 4. Syntax rules and ABNF for the format keyword values, unless
>    "anything goes".
> 
> 5. Semantic rules for format value keywords, e.g. are they
>    case-insensitive.

That's already covered in section 5.1 of RFC 2045.

>>Another thing that is specified here is that separator lines (at the
>>least) must be encoded to prevent local collisions, when an mbox
>>attachment is saved into an existing local folder (messages can become
>>irreversible mingled if some kind of escaping is not performed).
> 
> Since the format differs from canonical message format, and as there
> appears to be provision for encoding parts of the media type (using
> an unspecified encoding algorithm), it appears that several items are
> missing regarding such encoding:
> 
> 1. encoding algorithm(s) and corresponding decoding algorithm(s)

this is just transfer encoding, although I guess this point needs
clarification

> In the registration temple, the magic number could be indicated as
> 0x46726F6D20 ("From ").

good idea

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: blilly at erols.com (Bruce Lilly)
Date: Sun Jan 30 20:36:01 2005
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed January 26 2005 14:57, Eric A. Hall wrote:
> 
> The ADs for the applications area are going to move this into last-call
> again, but we all want to run it back up the flagpole one more time.
> 
> This version departs from earlier releases by specifying a "format"
> parameter to the application/mbox media-type, by defining a "default"
> value for the parameter,

Several things are missing related to that:

1. A registration procedure for registering new format value keywords
   (that could be, and probably should be, a separate document).

2. An IANA Considerations section related to establishment of a
   format value keyword registry (containing the "default" entry),
   and maintenance of that registry in conjunction with the
   registration procedure.

3. Location of the format value keyword registry (so that implementors
   can find the registry).  That should be coordinated with IANA.

4. Syntax rules and ABNF for the format keyword values, unless
   "anything goes".

5. Semantic rules for format value keywords, e.g. are they
   case-insensitive.

6. Provision, if any, for private-use or experimental format value
   keywords (e.g. reservation of keywords beginning with"x-" for
   such purposes).

[...]
> The "default" format uses a sequence of 822 messages, with the exception
> that line-endings are LF instead of CR/LF (this only applies to the
> canonical database, and doesn't affect the transfer protocol or anything
> else).
[...]
> Another thing that is specified here is that separator lines (at the
> least) must be encoded to prevent local collisions, when an mbox
> attachment is saved into an existing local folder (messages can become
> irreversible mingled if some kind of escaping is not performed).

Since the format differs from canonical message format, and as there
appears to be provision for encoding parts of the media type (using
an unspecified encoding algorithm), it appears that several items are
missing regarding such encoding:

1. encoding algorithm(s) and corresponding decoding algorithm(s)

2. how the particular encoding algorithm used by the originator is
   specified with the media type so that it can be reversed by the
   recipient.

3. interaction between any transfer encoding (RFC 2045) which may
   be present in messages and the encoding algorithms above

4. if it is possible to have the entire media type encoded or
   only  portions ("at the least") encoded, how the recipient can
   determine which is the case, and how to identify which portions
   are encoded so that appropriate decoding -- of those portions
   only -- can be performed w/o mangling unencoded portions, even
   if those unencoded portions contain content which has octet
   sequences resembling encoded portions. [I suspect that partial
   encoding won't work, and that the entire media type would have
   to be encoded/decoded as a unit.]

5. Interaction of encoding mechanisms and modifications that may
   occur during transport (message/partial fragmentation, addition
   of spurious whitespace, removal of trailing whitespace, etc.).

6. Since the media type format contains lone LF octets, it is
   unsuitable for transfer w/o transfer encoding (RFC 2822 section
   2.3); it is therefore possible that:
   a) a message within an mbox may have had RFC 2045 transfer
      encoding applied to a body MIME-part, with a corresponding
      Content-Transfer-Encoding field
   b) CRLF sequences delimiting lines may have been changed to LF
   c) some encoding may be applied to all or portions of the media
      type for the purpose of escaping "separator lines"
   d) transfer encoding may have to be applied to the media type
      for transfer, as it would otherwise contain non-conforming
      octet sequences (LF not immediately preceded by CR (RFC 2822
      sect. 2.3)
   In order to recover content end-to-end, it is necessary to
   specify the order of the various transformations and the
   corresponding decoding sequence, to prevent undesirable
   interaction between encoding/decoding operations that would
   alter message content.

In the registration temple, the magic number could be indicated as
0x46726F6D20 ("From ").
>From [email-masked]  Sun Jan 30 21:10:19 2005
From: ehall at ehsco.com (Eric A. Hall)
Date: Sun Jan 30 21:11:14 2005
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 1/30/2005 11:24 AM, Bruce Lilly wrote:

> 2. An IANA Considerations section related to establishment of a
>    format value keyword registry (containing the "default" entry),
>    and maintenance of that registry in conjunction with the
>    registration procedure.

Yeah probably.

> 4. Syntax rules and ABNF for the format keyword values, unless
>    "anything goes".
> 
> 5. Semantic rules for format value keywords, e.g. are they
>    case-insensitive.

That's already covered in section 5.1 of RFC 2045.

>>Another thing that is specified here is that separator lines (at the
>>least) must be encoded to prevent local collisions, when an mbox
>>attachment is saved into an existing local folder (messages can become
>>irreversible mingled if some kind of escaping is not performed).
> 
> Since the format differs from canonical message format, and as there
> appears to be provision for encoding parts of the media type (using
> an unspecified encoding algorithm), it appears that several items are
> missing regarding such encoding:
> 
> 1. encoding algorithm(s) and corresponding decoding algorithm(s)

this is just transfer encoding, although I guess this point needs
clarification

> In the registration temple, the magic number could be indicated as
> 0x46726F6D20 ("From ").

good idea

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>From [email-masked]  Wed Jan  5 00:11:06 2005
From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Tue Jan  3 16:22:53 2006
Subject: Registration of media type "application/nss"
In-Reply-To: <20041231005848.ZRJR16610.lakermmtao08.cox.net@A31P>
Message-ID: <20050104230905.LIRU16431.lakermmtao05.cox.net@A31P>

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:[email-masked]] 
> Sent: Thursday, December 30, 2004 7:59 PM
> To: 'Mike Hammer'; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent: Thursday, December 30, 2004 1:52 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > 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: [email-masked]
> > 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:  [email-masked]
> >    Author/Change controller:  ITU-T Study Group 11
> > 
> > END
> > 
> > 
> 
> 

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:54 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed January 26 2005 14:57, Eric A. Hall wrote:
> 
> The ADs for the applications area are going to move this into last-call
> again, but we all want to run it back up the flagpole one more time.
> 
> This version departs from earlier releases by specifying a "format"
> parameter to the application/mbox media-type, by defining a "default"
> value for the parameter,

Several things are missing related to that:

1. A registration procedure for registering new format value keywords
   (that could be, and probably should be, a separate document).

2. An IANA Considerations section related to establishment of a
   format value keyword registry (containing the "default" entry),
   and maintenance of that registry in conjunction with the
   registration procedure.

3. Location of the format value keyword registry (so that implementors
   can find the registry).  That should be coordinated with IANA.

4. Syntax rules and ABNF for the format keyword values, unless
   "anything goes".

5. Semantic rules for format value keywords, e.g. are they
   case-insensitive.

6. Provision, if any, for private-use or experimental format value
   keywords (e.g. reservation of keywords beginning with"x-" for
   such purposes).

[...]
> The "default" format uses a sequence of 822 messages, with the exception
> that line-endings are LF instead of CR/LF (this only applies to the
> canonical database, and doesn't affect the transfer protocol or anything
> else).
[...]
> Another thing that is specified here is that separator lines (at the
> least) must be encoded to prevent local collisions, when an mbox
> attachment is saved into an existing local folder (messages can become
> irreversible mingled if some kind of escaping is not performed).

Since the format differs from canonical message format, and as there
appears to be provision for encoding parts of the media type (using
an unspecified encoding algorithm), it appears that several items are
missing regarding such encoding:

1. encoding algorithm(s) and corresponding decoding algorithm(s)

2. how the particular encoding algorithm used by the originator is
   specified with the media type so that it can be reversed by the
   recipient.

3. interaction between any transfer encoding (RFC 2045) which may
   be present in messages and the encoding algorithms above

4. if it is possible to have the entire media type encoded or
   only  portions ("at the least") encoded, how the recipient can
   determine which is the case, and how to identify which portions
   are encoded so that appropriate decoding -- of those portions
   only -- can be performed w/o mangling unencoded portions, even
   if those unencoded portions contain content which has octet
   sequences resembling encoded portions. [I suspect that partial
   encoding won't work, and that the entire media type would have
   to be encoded/decoded as a unit.]

5. Interaction of encoding mechanisms and modifications that may
   occur during transport (message/partial fragmentation, addition
   of spurious whitespace, removal of trailing whitespace, etc.).

6. Since the media type format contains lone LF octets, it is
   unsuitable for transfer w/o transfer encoding (RFC 2822 section
   2.3); it is therefore possible that:
   a) a message within an mbox may have had RFC 2045 transfer
      encoding applied to a body MIME-part, with a corresponding
      Content-Transfer-Encoding field
   b) CRLF sequences delimiting lines may have been changed to LF
   c) some encoding may be applied to all or portions of the media
      type for the purpose of escaping "separator lines"
   d) transfer encoding may have to be applied to the media type
      for transfer, as it would otherwise contain non-conforming
      octet sequences (LF not immediately preceded by CR (RFC 2822
      sect. 2.3)
   In order to recover content end-to-end, it is necessary to
   specify the order of the various transformations and the
   corresponding decoding sequence, to prevent undesirable
   interaction between encoding/decoding operations that would
   alter message content.

In the registration temple, the magic number could be indicated as
0x46726F6D20 ("From ").

From: iana at iana.org ([email-masked])
Date: Sat Jan 29 05:51:07 2005
Subject: ConfirmSystem: [email-masked] [[60b84673d8300f72]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=60b84673d8300f72&l=[email-masked]>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Delivery service mail"
       
and it arrived at IANA approximately at Fri Jan 28 20:51:00 2005.

---------------------------------------------------------------
ConfirmSystem: [email-masked] [[60b84673d8300f72]]
1

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:54 2006
Subject: ConfirmSystem: [email-masked] [[60b84673d8300f72]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=60b84673d8300f72&l=[email-masked]>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Delivery service mail"
       
and it arrived at IANA approximately at Fri Jan 28 20:51:00 2005.

---------------------------------------------------------------
ConfirmSystem: [email-masked] [[60b84673d8300f72]]
1

From: iana at iana.org ([email-masked])
Date: Thu Jan 27 18:01:05 2005
Subject: ConfirmSystem: [email-masked] [[1f8c0c2f29dfa1c5]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=1f8c0c2f29dfa1c5&l=[email-masked]>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Delivery by mail"
       
and it arrived at IANA approximately at Thu Jan 27 09:00:57 2005.

---------------------------------------------------------------
ConfirmSystem: [email-masked] [[1f8c0c2f29dfa1c5]]
1

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:54 2006
Subject: ConfirmSystem: [email-masked] [[1f8c0c2f29dfa1c5]]
Message-ID: <[email-masked]>

Thank you for your message.

The [email-masked] address collects a tremendous amount of spam, and we
have been forced to implement protective measures.  In order to process
your message we need to confirm that it came from a real email address. 
To confirm your message, you can either:

  1) Reply to this message, without altering the subject line 
    The "Re: " added by many mail clients is OK, but please note
    that this method is *not* foolproof.  

or

  2) Visit the URL
        <http://confirm.icann.org/?s=1f8c0c2f29dfa1c5&l=[email-masked]>

If you want to be very sure that your message gets through, do both steps
above -- it does no harm to confirm more than once.

For your reference, the subject of the message you sent was:

  "{Filename?} Delivery by mail"
       
and it arrived at IANA approximately at Thu Jan 27 09:00:57 2005.

---------------------------------------------------------------
ConfirmSystem: [email-masked] [[1f8c0c2f29dfa1c5]]
1

From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Thu Jan 27 15:08:34 2005
Subject: Media Types review for application/simple-filter+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> > 2. Section 3.2 of 3688 describes what gets registered when 
> registering  
> > an
> > XML namespace.  It says "XML Namespaces ... are named by a 
> URI.  They  
> > have
> > no real, machine-parsable representation".  Yet the 
> template includes a
> > chunk of XML to be registered.  It's not needed, so why is it  
> > included?  All
> > that needs to be registered is the  
> > urn:ietf:params:xml:ns:simple-filter URN.
> 
> That's how I've seen it done. Check out
> 
> http://www.ietf.org/rfc/rfc3858.txt
> and
> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing 
> -03.txt (in author's 48 hours)

I'm aware of other instances like the ones you've pointed out.  Frankly,
though, I think they're wrong.  There's nothing in 3688 that talks about
registering any XML as part of registering an XML namespace.  It's not
needed, so it should be removed.

-Scott-

From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Types review for application/simple-filter+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> > 2. Section 3.2 of 3688 describes what gets registered when 
> registering  
> > an
> > XML namespace.  It says "XML Namespaces ... are named by a 
> URI.  They  
> > have
> > no real, machine-parsable representation".  Yet the 
> template includes a
> > chunk of XML to be registered.  It's not needed, so why is it  
> > included?  All
> > that needs to be registered is the  
> > urn:ietf:params:xml:ns:simple-filter URN.
> 
> That's how I've seen it done. Check out
> 
> http://www.ietf.org/rfc/rfc3858.txt
> and
> http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing 
> -03.txt (in author's 48 hours)

I'm aware of other instances like the ones you've pointed out.  Frankly,
though, I think they're wrong.  There's nothing in 3688 that talks about
registering any XML as part of registering an XML namespace.  It's not
needed, so it should be removed.

-Scott-

From: hisham.khartabil at telio.no (Hisham Khartabil)
Date: Thu Jan 27 15:03:31 2005
Subject: Media Types review for application/simple-filter+xml
In-Reply-To: <20050127131018.QAYU1713.lakermmtao09.cox.net@A31P>
References: <20050127131018.QAYU1713.lakermmtao09.cox.net@A31P>
Message-ID: <[email-masked]>

On Jan 27, 2005, at 2:12 PM, Scott Hollenbeck wrote:

> Two comments.  The first is on the namespace registration template  
> found in
> section 8.2.  It says:
>
> "This section registers a new XML namespace, as per guidelines in URN
> document [4]."  [4] is:
>
> [4]   Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
>
> There are two problems with the above.
>
> 1. 3688 isn't really a URN document.  It describes procedures to  
> register
> URNs, but it is better described as the "IETF XML Registry".

Ok.

>
> 2. Section 3.2 of 3688 describes what gets registered when registering  
> an
> XML namespace.  It says "XML Namespaces ... are named by a URI.  They  
> have
> no real, machine-parsable representation".  Yet the template includes a
> chunk of XML to be registered.  It's not needed, so why is it  
> included?  All
> that needs to be registered is the  
> urn:ietf:params:xml:ns:simple-filter URN.

That's how I've seen it done. Check out

http://www.ietf.org/rfc/rfc3858.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing 
-03.txt (in author's 48 hours)

>
> Second comment: the schema in section 6 includes several elements and
> attributes that allow extensibility, including "<xs:anyAttribute
> namespace="##other" processContents="lax"/>" and "<xs:any
> namespace="##other" processContents="lax" minOccurs="0"
> maxOccurs="unbounded"/>".  I don't see any text in the document  
> describing
> just how these extension elements and attributes are supposed to be  
> used,
> though.  You really should add some text to describe the extensibility
> framework.  What's allowed?  What isn't?  What needs to be done to  
> avoid
> namespace collisions and version conflicts?

Will add some text.

Thanks,
Hisham

>
> -Scott-
>
>> -----Original Message-----
>> From: Hisham Khartabil [mailto:[email-masked]]
>> Sent: Wednesday, January 26, 2005 9:21 AM
>> To: [email-masked]
>> Cc: Ted Hardie; Robert Sparks
>> Subject: Media Types review for application/simple-filter+xml
>>
>> The SIMPLE Working Group requests a Media Type review for the
>> following new type:
>>
>> - application/simple-filter+xml
>>
>> This is intended for the IETF tree, and specified in section
>> 8.1 of
>> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format
>> -04.txt
>>
>> Thanks,
>> Hisham Khartabil
>> SIMPLE WG Co-chair
>

From: hisham.khartabil at telio.no (Hisham Khartabil)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Types review for application/simple-filter+xml
In-Reply-To: <20050127131018.QAYU1713.lakermmtao09.cox.net@A31P>
References: <20050127131018.QAYU1713.lakermmtao09.cox.net@A31P>
Message-ID: <[email-masked]>

On Jan 27, 2005, at 2:12 PM, Scott Hollenbeck wrote:

> Two comments.  The first is on the namespace registration template  
> found in
> section 8.2.  It says:
>
> "This section registers a new XML namespace, as per guidelines in URN
> document [4]."  [4] is:
>
> [4]   Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
>
> There are two problems with the above.
>
> 1. 3688 isn't really a URN document.  It describes procedures to  
> register
> URNs, but it is better described as the "IETF XML Registry".

Ok.

>
> 2. Section 3.2 of 3688 describes what gets registered when registering  
> an
> XML namespace.  It says "XML Namespaces ... are named by a URI.  They  
> have
> no real, machine-parsable representation".  Yet the template includes a
> chunk of XML to be registered.  It's not needed, so why is it  
> included?  All
> that needs to be registered is the  
> urn:ietf:params:xml:ns:simple-filter URN.

That's how I've seen it done. Check out

http://www.ietf.org/rfc/rfc3858.txt
and
http://www.ietf.org/internet-drafts/draft-ietf-simple-iscomposing 
-03.txt (in author's 48 hours)

>
> Second comment: the schema in section 6 includes several elements and
> attributes that allow extensibility, including "<xs:anyAttribute
> namespace="##other" processContents="lax"/>" and "<xs:any
> namespace="##other" processContents="lax" minOccurs="0"
> maxOccurs="unbounded"/>".  I don't see any text in the document  
> describing
> just how these extension elements and attributes are supposed to be  
> used,
> though.  You really should add some text to describe the extensibility
> framework.  What's allowed?  What isn't?  What needs to be done to  
> avoid
> namespace collisions and version conflicts?

Will add some text.

Thanks,
Hisham

>
> -Scott-
>
>> -----Original Message-----
>> From: Hisham Khartabil [mailto:[email-masked]]
>> Sent: Wednesday, January 26, 2005 9:21 AM
>> To: [email-masked]
>> Cc: Ted Hardie; Robert Sparks
>> Subject: Media Types review for application/simple-filter+xml
>>
>> The SIMPLE Working Group requests a Media Type review for the
>> following new type:
>>
>> - application/simple-filter+xml
>>
>> This is intended for the IETF tree, and specified in section
>> 8.1 of
>> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format
>> -04.txt
>>
>> Thanks,
>> Hisham Khartabil
>> SIMPLE WG Co-chair
>

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan  3 16:22:54 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
Message-ID: <[email-masked]>

The ADs for the applications area are going to move this into last-call
again, but we all want to run it back up the flagpole one more time.

This version departs from earlier releases by specifying a "format"
parameter to the application/mbox media-type, by defining a "default"
value for the parameter, and by defining a default mbox database format
that must be supported.

The use of a format parameter allows different implementations to be
documented, and for them to be specified in the transfer (eg, a "SunOS"
format might specify the use of content-length and other things).
Unrecognized formats are to be treated as application/octet-stream.

The "default" format uses a sequence of 822 messages, with the exception
that line-endings are LF instead of CR/LF (this only applies to the
canonical database, and doesn't affect the transfer protocol or anything
else). Inheriting 822 rules means that email addresses must be qualified,
encodings must be specified, etc. All implementations have to support this
default format, and unspecified formats must be treated as "default" (this
is mostly for the benefit of protocols like HTTP, where parameters are not
always (or even usually) defined.

Another thing that is specified here is that separator lines (at the
least) must be encoded to prevent local collisions, when an mbox
attachment is saved into an existing local folder (messages can become
irreversible mingled if some kind of escaping is not performed).

There's one problem in this that I caught after submission, which is that
">From" escaping is specified, but shouldn't be. ">From" escaping is not
needed for transfers, and it's mostly a local matter anyway (having to do
with local parsing), and it's damn near impossible to deal with all the
potential exceptions (such as doubled escapes against quoted text, for
example), so it's really best not to specify anything. I'll roll this
change into any other comments that I get for the -04 version.

Anyway, any other comments are appreciated, as usual.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
-------------- next part --------------
An embedded message was scrubbed...
From: [email-masked]
Subject: I-D ACTION:draft-hall-mime-app-mbox-03.txt
Date: Mon, 24 Jan 2005 15:39:27 -0500
Size: 5167
Url: http://www.alvestrand.no/pipermail/ietf-types/attachments/20050126/954743df/draft-hall-mime-app-mbox-03.mht
>From [email-masked]  Tue Jan 25 17:53:45 2005
From: rohan at ekabal.com (Rohan Mahy)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<6.0.0.20.2.20050125082746.076889e0@localhost>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi,

This format is unlikely to be fetched from a web server, but if it is,  
the behavior described for .xml sounds appropriate to me.  Since this  
format is unlikely to be stored permanently in a file system it makes  
sense not to reserve a new 3-character extension.

thanks,
-rohan

On Jan 24, 2005, at 17:39, Bjoern Hoehrmann wrote:
> * Martin Duerst wrote:
>> At 04:30 05/01/25, Bjoern Hoehrmann wrote:
>>> * Allison Mankin wrote:
>>>> The Transport Area requests a Media Type review for the proposed
>>>> new type application/dialog-info+xml, intended for the IETF tree,  
>>>> and specified
>>>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog- 
>>>> package-05.txt
>>>> (Section 8.1).
>>>
>>> Why does it list .xml as file extension?
>>
>> Is there anything wrong with using a .xml extension? If yes, what?
>
> Well, e.g. RFC 3236 states:
>
> [...]
>   It is not recommended that the ".xml" extension (defined in
>   [XMLMIME]) be used, as web servers may be configured to
>   distribute such content as type "text/xml" or
>   "application/xml".  [XMLMIME] discusses the unreliability of
>   this approach in section 3.  Of course, should the author
>   desire this behaviour, then the ".xml" extension can be used.
> [...]
> -- 
> Bj?rn H?hrmann ? mailto:[email-masked] ?  
> http://bjoern.hoehrmann.de
> Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ?  
> http://www.bjoernsworld.de
> 68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/

From: hisham.khartabil at telio.no (Hisham Khartabil)
Date: Wed Jan 26 22:44:25 2005
Subject: Media Types review for application/simple-filter+xml
Message-ID: <[email-masked]>

The SIMPLE Working Group requests a Media Type review for the following  
new type:

- application/simple-filter+xml

This is intended for the IETF tree, and specified in section 8.1 of  
http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format 
-04.txt

Thanks,
Hisham Khartabil
SIMPLE WG Co-chair

From: hisham.khartabil at telio.no (Hisham Khartabil)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Types review for application/simple-filter+xml
Message-ID: <[email-masked]>

The SIMPLE Working Group requests a Media Type review for the following  
new type:

- application/simple-filter+xml

This is intended for the IETF tree, and specified in section 8.1 of  
http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format 
-04.txt

Thanks,
Hisham Khartabil
SIMPLE WG Co-chair

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <6.0.0.20.2.20050125082746.076889e0@localhost> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jan 25, 2005 at 02:39:17AM +0100, Bjoern Hoehrmann wrote:
> * Martin Duerst wrote:
> >At 04:30 05/01/25, Bjoern Hoehrmann wrote:
> > >* Allison Mankin wrote:
> > >>The Transport Area requests a Media Type review for the proposed
> > >>new type application/dialog-info+xml, intended for the IETF tree, and specified
> > >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
> > >>(Section 8.1).
> > >
> > >Why does it list .xml as file extension?
> >
> >Is there anything wrong with using a .xml extension? If yes, what?
> 
> Well, e.g. RFC 3236 states:
> 
> [...]
>   It is not recommended that the ".xml" extension (defined in
>   [XMLMIME]) be used, as web servers may be configured to
>   distribute such content as type "text/xml" or
>   "application/xml".  [XMLMIME] discusses the unreliability of
>   this approach in section 3.  Of course, should the author
>   desire this behaviour, then the ".xml" extension can be used.
> [...]

Yes, I was surprised I managed to get away with including that, given
the penchant for the use of */xml types at the time (and to this day,
it seems).  The relevant paragraph from section 3 is this;

  An XML document labeled as text/xml or application/xml might contain
  namespace declarations, stylesheet-linking processing instructions
  (PIs), schema information, or other declarations that might be used
  to suggest how the document is to be processed.  For example, a
  document might have the XHTML namespace and a reference to a CSS
  stylesheet.  Such a document might be handled by applications that
  would use this information to dispatch the document for appropriate
  processing.

Emphasis on "might".

Said another way, there is no specification which licenses a recipient
of a */xml-described (say) XHTML document, to infer that the sender
intended the message to convey XHTML semantics.  Therefore, using a
.xml extension provides different semantics than using the .dif
extension.  Unless this is desirable - which I seriously doubt - I
agree that .xml should be excluded.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <6.0.0.20.2.20050125082746.076889e0@localhost>
References: <[email-masked]> <[email-masked]> <6.0.0.20.2.20050125082746.076889e0@localhost>
Message-ID: <[email-masked]>

* Martin Duerst wrote:
>At 04:30 05/01/25, Bjoern Hoehrmann wrote:
> >* Allison Mankin wrote:
> >>The Transport Area requests a Media Type review for the proposed
> >>new type application/dialog-info+xml, intended for the IETF tree, and specified
> >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
> >>(Section 8.1).
> >
> >Why does it list .xml as file extension?
>
>Is there anything wrong with using a .xml extension? If yes, what?

Well, e.g. RFC 3236 states:

[...]
  It is not recommended that the ".xml" extension (defined in
  [XMLMIME]) be used, as web servers may be configured to
  distribute such content as type "text/xml" or
  "application/xml".  [XMLMIME] discusses the unreliability of
  this approach in section 3.  Of course, should the author
  desire this behaviour, then the ".xml" extension can be used.
[...]
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan 25 02:35:33 2005
Subject: Media Type review request for application/dialog-info+xml 
In-Reply-To: Your message of Tue, 25 Jan 2005 08:08:22 +0900. <6.0.0.20.2.20050125080735.055ace98@localhost> 
Message-ID: <[email-masked]>

Hi, Martin,

The media type registration document says to register ietf
tree types to the IESG, but it has struck me that if the
working group is* extant, it has more useful information than
the IESG would.  So just last week, the IESG discussed and informally
backed  this change controller formulation where the working group is
delegated from the iesg.  I suggest that the not-quite
final registration draft include that this is legal language,
and that if the working group change controller is found to be
concluded, then the change controller reverts to the IESG.

Allison
>From [email-masked]  Tue Jan 25 02:39:17 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan 25 02:38:38 2005
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <6.0.0.20.2.20050125082746.076889e0@localhost>
References: <[email-masked]>
	<[email-masked]>
	<6.0.0.20.2.20050125082746.076889e0@localhost>
Message-ID: <[email-masked]>

* Martin Duerst wrote:
>At 04:30 05/01/25, Bjoern Hoehrmann wrote:
> >* Allison Mankin wrote:
> >>The Transport Area requests a Media Type review for the proposed
> >>new type application/dialog-info+xml, intended for the IETF tree, and specified
> >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
> >>(Section 8.1).
> >
> >Why does it list .xml as file extension?
>
>Is there anything wrong with using a .xml extension? If yes, what?

Well, e.g. RFC 3236 states:

[...]
  It is not recommended that the ".xml" extension (defined in
  [XMLMIME]) be used, as web servers may be configured to
  distribute such content as type "text/xml" or
  "application/xml".  [XMLMIME] discusses the unreliability of
  this approach in section 3.  Of course, should the author
  desire this behaviour, then the ".xml" extension can be used.
[...]
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Tue Jan 25 19:52:50 2005
From: distobj at acm.org (Mark Baker)
Date: Tue Jan 25 19:53:10 2005
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<6.0.0.20.2.20050125082746.076889e0@localhost>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jan 25, 2005 at 02:39:17AM +0100, Bjoern Hoehrmann wrote:
> * Martin Duerst wrote:
> >At 04:30 05/01/25, Bjoern Hoehrmann wrote:
> > >* Allison Mankin wrote:
> > >>The Transport Area requests a Media Type review for the proposed
> > >>new type application/dialog-info+xml, intended for the IETF tree, and specified
> > >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
> > >>(Section 8.1).
> > >
> > >Why does it list .xml as file extension?
> >
> >Is there anything wrong with using a .xml extension? If yes, what?
> 
> Well, e.g. RFC 3236 states:
> 
> [...]
>   It is not recommended that the ".xml" extension (defined in
>   [XMLMIME]) be used, as web servers may be configured to
>   distribute such content as type "text/xml" or
>   "application/xml".  [XMLMIME] discusses the unreliability of
>   this approach in section 3.  Of course, should the author
>   desire this behaviour, then the ".xml" extension can be used.
> [...]

Yes, I was surprised I managed to get away with including that, given
the penchant for the use of */xml types at the time (and to this day,
it seems).  The relevant paragraph from section 3 is this;

  An XML document labeled as text/xml or application/xml might contain
  namespace declarations, stylesheet-linking processing instructions
  (PIs), schema information, or other declarations that might be used
  to suggest how the document is to be processed.  For example, a
  document might have the XHTML namespace and a reference to a CSS
  stylesheet.  Such a document might be handled by applications that
  would use this information to dispatch the document for appropriate
  processing.

Emphasis on "might".

Said another way, there is no specification which licenses a recipient
of a */xml-described (say) XHTML document, to infer that the sender
intended the message to convey XHTML semantics.  Therefore, using a
.xml extension provides different semantics than using the .dif
extension.  Unless this is desirable - which I seriously doubt - I
agree that .xml should be excluded.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Wed Jan 26 20:57:12 2005
From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Jan 26 20:57:19 2005
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
Message-ID: <[email-masked]>

The ADs for the applications area are going to move this into last-call
again, but we all want to run it back up the flagpole one more time.

This version departs from earlier releases by specifying a "format"
parameter to the application/mbox media-type, by defining a "default"
value for the parameter, and by defining a default mbox database format
that must be supported.

The use of a format parameter allows different implementations to be
documented, and for them to be specified in the transfer (eg, a "SunOS"
format might specify the use of content-length and other things).
Unrecognized formats are to be treated as application/octet-stream.

The "default" format uses a sequence of 822 messages, with the exception
that line-endings are LF instead of CR/LF (this only applies to the
canonical database, and doesn't affect the transfer protocol or anything
else). Inheriting 822 rules means that email addresses must be qualified,
encodings must be specified, etc. All implementations have to support this
default format, and unspecified formats must be treated as "default" (this
is mostly for the benefit of protocols like HTTP, where parameters are not
always (or even usually) defined.

Another thing that is specified here is that separator lines (at the
least) must be encoded to prevent local collisions, when an mbox
attachment is saved into an existing local folder (messages can become
irreversible mingled if some kind of escaping is not performed).

There's one problem in this that I caught after submission, which is that
">From" escaping is specified, but shouldn't be. ">From" escaping is not
needed for transfers, and it's mostly a local matter anyway (having to do
with local parsing), and it's damn near impossible to deal with all the
potential exceptions (such as doubled escapes against quoted text, for
example), so it's really best not to specify anything. I'll roll this
change into any other comments that I get for the -04 version.

Anyway, any other comments are appreciated, as usual.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
-------------- next part --------------
An embedded message was scrubbed...
From: [email-masked]
Subject: I-D ACTION:draft-hall-mime-app-mbox-03.txt
Date: Mon, 24 Jan 2005 15:39:27 -0500
Size: 5167
Url: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050126/954743df/draft-hall-mime-app-mbox-03.eml
>From [email-masked]  Tue Jan 25 17:53:45 2005
From: rohan at ekabal.com (Rohan Mahy)
Date: Wed Jan 26 22:44:23 2005
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<6.0.0.20.2.20050125082746.076889e0@localhost>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi,

This format is unlikely to be fetched from a web server, but if it is,  
the behavior described for .xml sounds appropriate to me.  Since this  
format is unlikely to be stored permanently in a file system it makes  
sense not to reserve a new 3-character extension.

thanks,
-rohan

On Jan 24, 2005, at 17:39, Bjoern Hoehrmann wrote:
> * Martin Duerst wrote:
>> At 04:30 05/01/25, Bjoern Hoehrmann wrote:
>>> * Allison Mankin wrote:
>>>> The Transport Area requests a Media Type review for the proposed
>>>> new type application/dialog-info+xml, intended for the IETF tree,  
>>>> and specified
>>>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog- 
>>>> package-05.txt
>>>> (Section 8.1).
>>>
>>> Why does it list .xml as file extension?
>>
>> Is there anything wrong with using a .xml extension? If yes, what?
>
> Well, e.g. RFC 3236 states:
>
> [...]
>   It is not recommended that the ".xml" extension (defined in
>   [XMLMIME]) be used, as web servers may be configured to
>   distribute such content as type "text/xml" or
>   "application/xml".  [XMLMIME] discusses the unreliability of
>   this approach in section 3.  Of course, should the author
>   desire this behaviour, then the ".xml" extension can be used.
> [...]
> -- 
> Bj?rn H?hrmann ? mailto:[email-masked] ?  
> http://bjoern.hoehrmann.de
> Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ?  
> http://www.bjoernsworld.de
> 68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml 
In-Reply-To: Your message of Tue, 25 Jan 2005 08:08:22 +0900. <6.0.0.20.2.20050125080735.055ace98@localhost> 
Message-ID: <[email-masked]>

Hi, Martin,

The media type registration document says to register ietf
tree types to the IESG, but it has struck me that if the
working group is* extant, it has more useful information than
the IESG would.  So just last week, the IESG discussed and informally
backed  this change controller formulation where the working group is
delegated from the iesg.  I suggest that the not-quite
final registration draft include that this is legal language,
and that if the working group change controller is found to be
concluded, then the change controller reverts to the IESG.

Allison

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan 25 02:26:14 2005
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <6.0.0.20.2.20050125082746.076889e0@localhost>

At 04:30 05/01/25, Bjoern Hoehrmann wrote:
 >* Allison Mankin wrote:
 >>The Transport Area requests a Media Type review for the proposed
 >>new type application/dialog-info+xml, intended for the IETF tree, and specified
 >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
 >>(Section 8.1).
 >
 >Why does it list .xml as file extension?

Hello Bjoern,

Is there anything wrong with using a .xml extension? If yes, what?

Regards,    Martin.

I think the .dif extension is
 >used for for application/vnd.ms-excel and video/dv already, did the
 >Working Group take that into account when choosing the extension?
 >--
 >Bj$B‹S(Bn H$B‹I(Brmann $B%-(B mailto:[email-masked] $B%-(B http://bjoern.hoehrmann.de
 >Weinh. Str. 22 $B%-(B Telefon: +49(0)621/4309674 $B%-(B http://www.bjoernsworld.de
 >68309 Mannheim $B%-(B PGP Pub. KeyID: 0xA4357E78 $B%-(B http://www.websitedev.de/ 

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <6.0.0.20.2.20050125082746.076889e0@localhost>

At 04:30 05/01/25, Bjoern Hoehrmann wrote:
 >* Allison Mankin wrote:
 >>The Transport Area requests a Media Type review for the proposed
 >>new type application/dialog-info+xml, intended for the IETF tree, and specified
 >>http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
 >>(Section 8.1).
 >
 >Why does it list .xml as file extension?

Hello Bjoern,

Is there anything wrong with using a .xml extension? If yes, what?

Regards,    Martin.

I think the .dif extension is
 >used for for application/vnd.ms-excel and video/dv already, did the
 >Working Group take that into account when choosing the extension?
 >--
 >Bj$B‹S(Bn H$B‹I(Brmann $B%-(B mailto:[email-masked] $B%-(B http://bjoern.hoehrmann.de
 >Weinh. Str. 22 $B%-(B Telefon: +49(0)621/4309674 $B%-(B http://www.bjoernsworld.de
 >68309 Mannheim $B%-(B PGP Pub. KeyID: 0xA4357E78 $B%-(B http://www.websitedev.de/ 

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20050125080735.055ace98@localhost>

At 04:17 05/01/25, Allison Mankin wrote:
 >
 >The Transport Area requests a Media Type review for the proposed
 >new type application/dialog-info+xml, intended for the IETF tree, and specified
 >http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
 >(Section 8.1).
 >
 >We know of the following needed changes:
 >
 >1. Author/Change Controller will be modified
 >to "SIPPING Working Group delegated from the IESG"

Does it make sense to have a WG as Change Controller?
IETF WGs are supposed to end, but change control doesn't end.

Regards,   Martin. 

From: eburger at brooktrout.com (Eric Burger)
Date: Tue Jan 25 00:06:06 2005
Subject: MIME Type Review for KPML MIME Types
Message-ID: <[email-masked]>

We did not, as message/* is for encapsulating user messages.  KPML is an
application PDU (application message).

> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:[email-masked]]
> Sent: Thursday, January 20, 2005 5:43 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: Re: MIME Type Review for KPML MIME Types
> 
> 
> * Eric Burger wrote:
> >KPML is in the process of WGLC in the SIPPING work group.
> >
> >KPML defines two new MIME types, application/kpml-request+xml and
> >application/kpml-response+xml .
> >
> >We would greatly appreciate expert review of the definition 
> and usage of
> >these new types.
> >
> >The draft lives at:
> >http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt
> 
> Did the Working Group consider using the message/* top-level type?
>From [email-masked]  Tue Jan 25 00:08:22 2005
From: duerst at w3.org (Martin Duerst)
Date: Tue Jan 25 02:26:09 2005
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <6.0.0.20.2.20050125080735.055ace98@localhost>

At 04:17 05/01/25, Allison Mankin wrote:
 >
 >The Transport Area requests a Media Type review for the proposed
 >new type application/dialog-info+xml, intended for the IETF tree, and specified
 >http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
 >(Section 8.1).
 >
 >We know of the following needed changes:
 >
 >1. Author/Change Controller will be modified
 >to "SIPPING Working Group delegated from the IESG"

Does it make sense to have a WG as Change Controller?
IETF WGs are supposed to end, but change control doesn't end.

Regards,   Martin. 

From: eburger at brooktrout.com (Eric Burger)
Date: Tue Jan  3 16:22:54 2006
Subject: MIME Type Review for KPML MIME Types
Message-ID: <[email-masked]>

We did not, as message/* is for encapsulating user messages.  KPML is an
application PDU (application message).

> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:[email-masked]]
> Sent: Thursday, January 20, 2005 5:43 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: Re: MIME Type Review for KPML MIME Types
> 
> 
> * Eric Burger wrote:
> >KPML is in the process of WGLC in the SIPPING work group.
> >
> >KPML defines two new MIME types, application/kpml-request+xml and
> >application/kpml-response+xml .
> >
> >We would greatly appreciate expert review of the definition 
> and usage of
> >these new types.
> >
> >The draft lives at:
> >http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt
> 
> Did the Working Group consider using the message/* top-level type?

From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Allison,

I found a few small schema errors when running the schema from section 4.4
through the IBM Schema Quality Checker.  They should be looked at (sorry if
the diagnostic lines below get broken in strange ways):

Initializing Schema Quality Checker. Please wait ...
SchemaQualityChecker has been initialized
PROCESSING test.xsd time : 2005-01-24T14:28:21 ...
test.xsd (file 1 of 1) now being read ...
ERROR
 file = file:test.xsd line 100 column 70
SEVERITY: 1
ERROR TYPE: 1
MESSAGE
cvc-complex-type.2.4.a: Invalid content starting with element
'xs:attribute'. One of '{"http://www.w3.org/2001/XMLSchema":unique,
"http://www.w3.org/2001/XMLSchema":key,
"http://www.w3.org/2001/XMLSchema":keyref}' is expected.

   ------------------------------------------------------------------------
ERROR
 file = file:test.xsd line 100 column 70
SEVERITY: 1
ERROR TYPE: 1
MESSAGE
cvc-complex-type.3.2.2: Attribute 'use' is not allowed to appear in element
'xs:attribute'.

   ------------------------------------------------------------------------
ERROR
 file = file:test.xsd line 85 column 41
SEVERITY: 1
ERROR TYPE: 1
MESSAGE
The reference nameaddr uses the empty string as its prefix. But there is no
namespace declaration which associates the empty string with a namespace. To
fix the problem, you may add the attribute "xmlns" in the root element
(<schema>)

   ------------------------------------------------------------------------
end time = 2005-01-24T14:28:24

-Scott-

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Mon Jan 24 20:29:48 2005
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* Allison Mankin wrote:
>The Transport Area requests a Media Type review for the proposed
>new type application/dialog-info+xml, intended for the IETF tree, and specified
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
>(Section 8.1).

Why does it list .xml as file extension? I think the .dif extension is
used for for application/vnd.ms-excel and video/dv already, did the
Working Group take that into account when choosing the extension?
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Mon Jan 24 20:35:54 2005
From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Mon Jan 24 20:35:56 2005
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Allison,

I found a few small schema errors when running the schema from section 4.4
through the IBM Schema Quality Checker.  They should be looked at (sorry if
the diagnostic lines below get broken in strange ways):

Initializing Schema Quality Checker. Please wait ...
SchemaQualityChecker has been initialized
PROCESSING test.xsd time : 2005-01-24T14:28:21 ...
test.xsd (file 1 of 1) now being read ...
ERROR
 file = file:test.xsd line 100 column 70
SEVERITY: 1
ERROR TYPE: 1
MESSAGE
cvc-complex-type.2.4.a: Invalid content starting with element
'xs:attribute'. One of '{"http://www.w3.org/2001/XMLSchema":unique,
"http://www.w3.org/2001/XMLSchema":key,
"http://www.w3.org/2001/XMLSchema":keyref}' is expected.

   ------------------------------------------------------------------------
ERROR
 file = file:test.xsd line 100 column 70
SEVERITY: 1
ERROR TYPE: 1
MESSAGE
cvc-complex-type.3.2.2: Attribute 'use' is not allowed to appear in element
'xs:attribute'.

   ------------------------------------------------------------------------
ERROR
 file = file:test.xsd line 85 column 41
SEVERITY: 1
ERROR TYPE: 1
MESSAGE
The reference nameaddr uses the empty string as its prefix. But there is no
namespace declaration which associates the empty string with a namespace. To
fix the problem, you may add the attribute "xmlns" in the root element
(<schema>)

   ------------------------------------------------------------------------
end time = 2005-01-24T14:28:24

-Scott-

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* Allison Mankin wrote:
>The Transport Area requests a Media Type review for the proposed
>new type application/dialog-info+xml, intended for the IETF tree, and specified
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
>(Section 8.1).

Why does it list .xml as file extension? I think the .dif extension is
used for for application/vnd.ms-excel and video/dv already, did the
Working Group take that into account when choosing the extension?
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: mankin at psg.com (Allison Mankin)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for application/dialog-info+xml
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed
new type application/dialog-info+xml, intended for the IETF tree, and specified
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
(Section 8.1).

We know of the following needed changes:

1. Author/Change Controller will be modified
to "SIPPING Working Group delegated from the IESG"

Please provide any comments as soon as possible.

Thanks,

Allison

From: distobj at acm.org (Mark Baker)
Date: Mon Jan 24 18:57:44 2005
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ok, thanks.

I already spam-filter a handful of Wikis and mailing lists, so adding
one more to the list wouldn't be a burden for me.  Yes, that's an
offer. 8-)

Mark.

On Mon, Jan 24, 2005 at 09:36:07AM -0800, WJCarpenter wrote:
> mb> Perhaps a naive question, but why is this list moderated?
> 
> mw> So that we don't have to receive lots of spam. I assume that this
> 
> Just so.  It's undesirable to have moderation, but it's pragmatically
> necessary.  Because it's an IETF list, Harald bends over backwards to
> keep away barriers from posting, invite free discussion, etc.
> However, just by the mere fact of having the posting address on
> various web sites, it attracts a *lot* of spam.
> 
> mw> a lot better than have to wade through the 10+ spam per day that
> 
> I long for the "good old days" when spam problems could be described
> in single or double digits.  I haven't looked at the numbers lately,
> but it's likely the ietf-types "raw feed" is some 3-digit number of
> spams per day.  Considering that in the average month there are
> probably only a dozen or so legitimate messages, well, you can see the
> situation is pretty bad.
> 
> So, as noted, subscribers have direct posting rights (no moderation),
> and non-subscribers go to an administrator queue.  It's obvious to a
> human what's legitimate and what's nonsense, but it's something that
> can't yet be turned over completely to automation.
> -- 
> [email-masked] (WJCarpenter)    PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3
> 

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Mon Jan 24 20:17:04 2005
From: mankin at psg.com (Allison Mankin)
Date: Mon Jan 24 20:17:08 2005
Subject: Media Type review request for application/dialog-info+xml
Message-ID: <[email-masked]>

The Transport Area requests a Media Type review for the proposed
new type application/dialog-info+xml, intended for the IETF tree, and specified
http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt
(Section 8.1).

We know of the following needed changes:

1. Author/Change Controller will be modified
to "SIPPING Working Group delegated from the IESG"

Please provide any comments as soon as possible.

Thanks,

Allison

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:54 2006
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ok, thanks.

I already spam-filter a handful of Wikis and mailing lists, so adding
one more to the list wouldn't be a burden for me.  Yes, that's an
offer. 8-)

Mark.

On Mon, Jan 24, 2005 at 09:36:07AM -0800, WJCarpenter wrote:
> mb> Perhaps a naive question, but why is this list moderated?
> 
> mw> So that we don't have to receive lots of spam. I assume that this
> 
> Just so.  It's undesirable to have moderation, but it's pragmatically
> necessary.  Because it's an IETF list, Harald bends over backwards to
> keep away barriers from posting, invite free discussion, etc.
> However, just by the mere fact of having the posting address on
> various web sites, it attracts a *lot* of spam.
> 
> mw> a lot better than have to wade through the 10+ spam per day that
> 
> I long for the "good old days" when spam problems could be described
> in single or double digits.  I haven't looked at the numbers lately,
> but it's likely the ietf-types "raw feed" is some 3-digit number of
> spams per day.  Considering that in the average month there are
> probably only a dozen or so legitimate messages, well, you can see the
> situation is pretty bad.
> 
> So, as noted, subscribers have direct posting rights (no moderation),
> and non-subscribers go to an administrator queue.  It's obvious to a
> human what's legitimate and what's nonsense, but it's something that
> can't yet be turned over completely to automation.
> -- 
> [email-masked] (WJCarpenter)    PGP 0x91865119
> 38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3
> 

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: bill-iana at carpenter.ORG (WJCarpenter)
Date: Tue Jan  3 16:22:54 2006
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

mb> Perhaps a naive question, but why is this list moderated?

mw> So that we don't have to receive lots of spam. I assume that this

Just so.  It's undesirable to have moderation, but it's pragmatically
necessary.  Because it's an IETF list, Harald bends over backwards to
keep away barriers from posting, invite free discussion, etc.
However, just by the mere fact of having the posting address on
various web sites, it attracts a *lot* of spam.

mw> a lot better than have to wade through the 10+ spam per day that

I long for the "good old days" when spam problems could be described
in single or double digits.  I haven't looked at the numbers lately,
but it's likely the ietf-types "raw feed" is some 3-digit number of
spams per day.  Considering that in the average month there are
probably only a dozen or so legitimate messages, well, you can see the
situation is pretty bad.

So, as noted, subscribers have direct posting rights (no moderation),
and non-subscribers go to an administrator queue.  It's obvious to a
human what's legitimate and what's nonsense, but it's something that
can't yet be turned over completely to automation.
-- 
[email-masked] (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Tue Jan  3 16:22:54 2006
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Mark Baker wrote:
> Perhaps a naive question, but why is this list moderated?
> 

So that we don't have to receive lots of spam. I assume that this list 
is using the same rule as most other IETF related list. Subscriber has 
direct posting, non-subscriber is moderated. That way the moderator can 
ensure that only valid postings are let through to the list. Sure, it is 
not 100% secure, but it is a hell of a lot better than have to wade 
through the 10+ spam per day that anyway would reach the list despite 
filtering.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

From: distobj at acm.org (Mark Baker)
Date: Mon Jan 24 17:09:51 2005
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Perhaps a naive question, but why is this list moderated?

Thanks.

Mark.

On Mon, Jan 24, 2005 at 01:56:43PM +0100, Harald Tveit Alvestrand wrote:
> Hello,
> 
> Bill Carpenter, who has long co-moderated the ietf-types list along with 
> me, has asked to drop out of the role.
> 
> At the same time, two events have emphasized the need for a co-moderator:
> 
> - A couple of requests and comments got severely delayed in the moderator 
> queue
> - I've scheduled a vacation for the month of April
> 
> Together, these things clearly indicate that someone needs to be on hand to 
> moderate the list - both when I'm here and when I'm gone.
> 
> The lists run on Mailman, behind a spam filter, and with an ancillary 
> script that deletes the more obvious spam from the queue. Still, there's 
> spam coming through - unfortunately.
> 
> Volunteers?
> 
> thanks in advance!
> 
>                 Harald
> 

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Mon Jan 24 17:14:56 2005
From: magnus.westerlund at ericsson.com (Magnus Westerlund)
Date: Mon Jan 24 17:15:09 2005
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Mark Baker wrote:
> Perhaps a naive question, but why is this list moderated?
> 

So that we don't have to receive lots of spam. I assume that this list 
is using the same rule as most other IETF related list. Subscriber has 
direct posting, non-subscriber is moderated. That way the moderator can 
ensure that only valid postings are let through to the list. Sure, it is 
not 100% secure, but it is a hell of a lot better than have to wade 
through the 10+ spam per day that anyway would reach the list despite 
filtering.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
>From [email-masked]  Mon Jan 24 18:36:07 2005
From: bill-iana at carpenter.ORG (WJCarpenter)
Date: Mon Jan 24 18:36:49 2005
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

mb> Perhaps a naive question, but why is this list moderated?

mw> So that we don't have to receive lots of spam. I assume that this

Just so.  It's undesirable to have moderation, but it's pragmatically
necessary.  Because it's an IETF list, Harald bends over backwards to
keep away barriers from posting, invite free discussion, etc.
However, just by the mere fact of having the posting address on
various web sites, it attracts a *lot* of spam.

mw> a lot better than have to wade through the 10+ spam per day that

I long for the "good old days" when spam problems could be described
in single or double digits.  I haven't looked at the numbers lately,
but it's likely the ietf-types "raw feed" is some 3-digit number of
spams per day.  Considering that in the average month there are
probably only a dozen or so legitimate messages, well, you can see the
situation is pretty bad.

So, as noted, subscribers have direct posting rights (no moderation),
and non-subscribers go to an administrator queue.  It's obvious to a
human what's legitimate and what's nonsense, but it's something that
can't yet be turned over completely to automation.
-- 
[email-masked] (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:54 2006
Subject: Seeking co-moderators(s) of the ietf-types list
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Perhaps a naive question, but why is this list moderated?

Thanks.

Mark.

On Mon, Jan 24, 2005 at 01:56:43PM +0100, Harald Tveit Alvestrand wrote:
> Hello,
> 
> Bill Carpenter, who has long co-moderated the ietf-types list along with 
> me, has asked to drop out of the role.
> 
> At the same time, two events have emphasized the need for a co-moderator:
> 
> - A couple of requests and comments got severely delayed in the moderator 
> queue
> - I've scheduled a vacation for the month of April
> 
> Together, these things clearly indicate that someone needs to be on hand to 
> moderate the list - both when I'm here and when I'm gone.
> 
> The lists run on Mailman, behind a spam filter, and with an ancillary 
> script that deletes the more obvious spam from the queue. Still, there's 
> spam coming through - unfortunately.
> 
> Volunteers?
> 
> thanks in advance!
> 
>                 Harald
> 

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Mon Jan 24 13:56:52 2005
Subject: Seeking co-moderators(s) of the ietf-types list
Message-ID: <[email-masked]>

Hello,

Bill Carpenter, who has long co-moderated the ietf-types list along with 
me, has asked to drop out of the role.

At the same time, two events have emphasized the need for a co-moderator:

- A couple of requests and comments got severely delayed in the moderator 
queue
- I've scheduled a vacation for the month of April

Together, these things clearly indicate that someone needs to be on hand to 
moderate the list - both when I'm here and when I'm gone.

The lists run on Mailman, behind a spam filter, and with an ancillary 
script that deletes the more obvious spam from the queue. Still, there's 
spam coming through - unfortunately.

Volunteers?

thanks in advance!

                 Harald

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Tue Jan  3 16:22:54 2006
Subject: Seeking co-moderators(s) of the ietf-types list
Message-ID: <[email-masked]>

Hello,

Bill Carpenter, who has long co-moderated the ietf-types list along with 
me, has asked to drop out of the role.

At the same time, two events have emphasized the need for a co-moderator:

- A couple of requests and comments got severely delayed in the moderator 
queue
- I've scheduled a vacation for the month of April

Together, these things clearly indicate that someone needs to be on hand to 
moderate the list - both when I'm here and when I'm gone.

The lists run on Mailman, behind a spam filter, and with an ancillary 
script that deletes the more obvious spam from the queue. Still, there's 
spam coming through - unfortunately.

Volunteers?

thanks in advance!

                 Harald

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:54 2006
Subject: Registration of MIME media type .pss
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <6.0.0.20.2.20050121081505.063a6738@localhost>

At 06:45 05/01/21, Chris Lilley wrote:
 >(same comments on the application/.ecc registration)
 >
 >On Thursday, December 9, 2004, 10:07:45 PM, Tony wrote:

 >TM>      Security considerations: none
 >
 >This is unlikely. Some indication should be given of why this data is
 >harmless. This is particularly the case in the absence of a published
 >specification.

Yes, and in addition particularly when looking at the applications
that use this type:

 >TM>      Applications which use this media type: Essential Security
 >TM> Software product, Essential Security Suite and Ecrypt-it. Contains
 >TM> encrypted information.

 >TM>
 >TM>      Interoperability considerations: none
 >TM>
 >TM>      Published specification: The specifications for this
 >TM> content type are proprietary. They are specified by Essential
 >TM> Security Software, Inc.
 >
 >In that case, would a vendor tree registration not be more appropriate?
 >
 >application/vnd.ess.pss
 >(note - not application/vnd..ess.pss )
 >
 >and similarly
 >
 >application/vnd.ess.ecc

Yes indeed.

Regards,    Martin. 

From: hgarudad at qualcomm.com (Harinath Garudadri)
Date: Wed Jan 26 22:44:28 2005
Subject: [AVT] Updated 3GPP2 MIME ID: draft-garudadri-avt-3gpp2-mime-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 10:49 AM 1/16/2005, Colin Perkins wrote:
>On 17 Dec 2004, at 22:19, Harinath Garudadri wrote:
>>  An updated version of the ID registering 3gpp2 MIME types is now
>>available at
>>http://www.ietf.org/internet-drafts/draft-garudadri-avt-3gpp2-mime 
>>-01.txt. This version uses the correct template and incorporates some
>>editorial changes.
>
>I have a few details that should be resolved:
>
>  - Please move the paragraph defining "Conventions used in this
>document" to
>    be part of the introduction, rather than being a separate section.
>Also,
>    please remove section 6 and add the text as an unnumbered note in the
>    boilerplate at the start of the draft.

Done. The latest draft can obtained from 
http://people.qualcomm.com/randy/draft-garudadri-avt-3gpp2-mime-02.txt if 
you need it before the ID appears at 
http://www.ietf.org/internet-drafts/draft-garudadri-avt-3gpp2-mime -02.txt

>  - Is there a need to register media types other than audio or video
>(the
>    most obvious being "text/3gpp2", to allow a future timed text
>format)?

3GPP2 timed text is same as 3GPP timed text. So, there is no need for other 
media types and we plan to use text/3gpp-tt

>Otherwise this draft looks reasonable to me, although I'm not a MIME
>expert. Once you've made these changes, you might consider asking for
>review on the <[email-masked]> mailing list.

I have copied <[email-masked]> in this thread. Is this adequate or do 
I need to do anything else?

Thanks,
hari.

>Colin

Dr. Hari Garudadri
Qualcomm Inc.
work    : +1 858 651 6383
mobile : +1 858 229 2801
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20050120/96e19386/attachment.htm
>From [email-masked]  Thu Jan 27 14:12:21 2005
From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Thu Jan 27 14:10:26 2005
Subject: Media Types review for application/simple-filter+xml
In-Reply-To: <[email-masked]>
Message-ID: <20050127131018.QAYU1713.lakermmtao09.cox.net@A31P>

Two comments.  The first is on the namespace registration template found in
section 8.2.  It says:

"This section registers a new XML namespace, as per guidelines in URN
document [4]."  [4] is:

[4]   Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

There are two problems with the above.

1. 3688 isn't really a URN document.  It describes procedures to register
URNs, but it is better described as the "IETF XML Registry".

2. Section 3.2 of 3688 describes what gets registered when registering an
XML namespace.  It says "XML Namespaces ... are named by a URI.  They have
no real, machine-parsable representation".  Yet the template includes a
chunk of XML to be registered.  It's not needed, so why is it included?  All
that needs to be registered is the urn:ietf:params:xml:ns:simple-filter URN.

Second comment: the schema in section 6 includes several elements and
attributes that allow extensibility, including "<xs:anyAttribute
namespace="##other" processContents="lax"/>" and "<xs:any
namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>".  I don't see any text in the document describing
just how these extension elements and attributes are supposed to be used,
though.  You really should add some text to describe the extensibility
framework.  What's allowed?  What isn't?  What needs to be done to avoid
namespace collisions and version conflicts?

-Scott-

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]] 
> Sent: Wednesday, January 26, 2005 9:21 AM
> To: [email-masked]
> Cc: Ted Hardie; Robert Sparks
> Subject: Media Types review for application/simple-filter+xml
> 
> The SIMPLE Working Group requests a Media Type review for the 
> following new type:
> 
> - application/simple-filter+xml
> 
> This is intended for the IETF tree, and specified in section 
> 8.1 of 
> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format
> -04.txt
> 
> Thanks,
> Hisham Khartabil
> SIMPLE WG Co-chair

From: hgarudad at qualcomm.com (Harinath Garudadri)
Date: Tue Jan  3 16:22:54 2006
Subject: [AVT] Updated 3GPP2 MIME ID: draft-garudadri-avt-3gpp2-mime-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

At 10:49 AM 1/16/2005, Colin Perkins wrote:
>On 17 Dec 2004, at 22:19, Harinath Garudadri wrote:
>>  An updated version of the ID registering 3gpp2 MIME types is now
>>available at
>>http://www.ietf.org/internet-drafts/draft-garudadri-avt-3gpp2-mime 
>>-01.txt. This version uses the correct template and incorporates some
>>editorial changes.
>
>I have a few details that should be resolved:
>
>  - Please move the paragraph defining "Conventions used in this
>document" to
>    be part of the introduction, rather than being a separate section.
>Also,
>    please remove section 6 and add the text as an unnumbered note in the
>    boilerplate at the start of the draft.

Done. The latest draft can obtained from 
http://people.qualcomm.com/randy/draft-garudadri-avt-3gpp2-mime-02.txt if 
you need it before the ID appears at 
http://www.ietf.org/internet-drafts/draft-garudadri-avt-3gpp2-mime -02.txt

>  - Is there a need to register media types other than audio or video
>(the
>    most obvious being "text/3gpp2", to allow a future timed text
>format)?

3GPP2 timed text is same as 3GPP timed text. So, there is no need for other 
media types and we plan to use text/3gpp-tt

>Otherwise this draft looks reasonable to me, although I'm not a MIME
>expert. Once you've made these changes, you might consider asking for
>review on the <[email-masked]> mailing list.

I have copied <[email-masked]> in this thread. Is this adequate or do 
I need to do anything else?

Thanks,
hari.

>Colin

Dr. Hari Garudadri
Qualcomm Inc.
work    : +1 858 651 6383
mobile : +1 858 229 2801
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20050120/96e19386/attachment.html
>From [email-masked]  Thu Jan 27 14:12:21 2005
From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Types review for application/simple-filter+xml
In-Reply-To: <[email-masked]>
Message-ID: <20050127131018.QAYU1713.lakermmtao09.cox.net@A31P>

Two comments.  The first is on the namespace registration template found in
section 8.2.  It says:

"This section registers a new XML namespace, as per guidelines in URN
document [4]."  [4] is:

[4]   Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

There are two problems with the above.

1. 3688 isn't really a URN document.  It describes procedures to register
URNs, but it is better described as the "IETF XML Registry".

2. Section 3.2 of 3688 describes what gets registered when registering an
XML namespace.  It says "XML Namespaces ... are named by a URI.  They have
no real, machine-parsable representation".  Yet the template includes a
chunk of XML to be registered.  It's not needed, so why is it included?  All
that needs to be registered is the urn:ietf:params:xml:ns:simple-filter URN.

Second comment: the schema in section 6 includes several elements and
attributes that allow extensibility, including "<xs:anyAttribute
namespace="##other" processContents="lax"/>" and "<xs:any
namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>".  I don't see any text in the document describing
just how these extension elements and attributes are supposed to be used,
though.  You really should add some text to describe the extensibility
framework.  What's allowed?  What isn't?  What needs to be done to avoid
namespace collisions and version conflicts?

-Scott-

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]] 
> Sent: Wednesday, January 26, 2005 9:21 AM
> To: [email-masked]
> Cc: Ted Hardie; Robert Sparks
> Subject: Media Types review for application/simple-filter+xml
> 
> The SIMPLE Working Group requests a Media Type review for the 
> following new type:
> 
> - application/simple-filter+xml
> 
> This is intended for the IETF tree, and specified in section 
> 8.1 of 
> http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format
> -04.txt
> 
> Thanks,
> Hisham Khartabil
> SIMPLE WG Co-chair

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:54 2006
Subject: Media Type review request for "application/resource-lists+xml" and "application/rls-services+xml"
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* Hisham Khartabil wrote:
>The SIMPLE Working Group requests a Media Type review for the following  
>2 new types:
>
>- application/resource-lists+xml
>- application/rls-services+xml
>
>These are intended for the IETF tree, and specified in section 8.2 of  
>http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage 
>-04.txt

Why does it list .xml as file extension? 
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu Jan 20 23:42:27 2005
Subject: MIME Type Review for KPML MIME Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* Eric Burger wrote:
>KPML is in the process of WGLC in the SIPPING work group.
>
>KPML defines two new MIME types, application/kpml-request+xml and
>application/kpml-response+xml .
>
>We would greatly appreciate expert review of the definition and usage of
>these new types.
>
>The draft lives at:
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt

Did the Working Group consider using the message/* top-level type?
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Thu Jan 20 23:46:20 2005
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu Jan 20 23:45:44 2005
Subject: Media Type review request for "application/resource-lists+xml"
	and "application/rls-services+xml"
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* Hisham Khartabil wrote:
>The SIMPLE Working Group requests a Media Type review for the following  
>2 new types:
>
>- application/resource-lists+xml
>- application/rls-services+xml
>
>These are intended for the IETF tree, and specified in section 8.2 of  
>http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage 
>-04.txt

Why does it list .xml as file extension? 
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 
>From [email-masked]  Fri Jan 21 04:28:26 2005
From: duerst at w3.org (Martin Duerst)
Date: Fri Jan 21 04:28:46 2005
Subject: Registration of MIME media type .pss
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <6.0.0.20.2.20050121081505.063a6738@localhost>

At 06:45 05/01/21, Chris Lilley wrote:
 >(same comments on the application/.ecc registration)
 >
 >On Thursday, December 9, 2004, 10:07:45 PM, Tony wrote:

 >TM>      Security considerations: none
 >
 >This is unlikely. Some indication should be given of why this data is
 >harmless. This is particularly the case in the absence of a published
 >specification.

Yes, and in addition particularly when looking at the applications
that use this type:

 >TM>      Applications which use this media type: Essential Security
 >TM> Software product, Essential Security Suite and Ecrypt-it. Contains
 >TM> encrypted information.

 >TM>
 >TM>      Interoperability considerations: none
 >TM>
 >TM>      Published specification: The specifications for this
 >TM> content type are proprietary. They are specified by Essential
 >TM> Security Software, Inc.
 >
 >In that case, would a vendor tree registration not be more appropriate?
 >
 >application/vnd.ess.pss
 >(note - not application/vnd..ess.pss )
 >
 >and similarly
 >
 >application/vnd.ess.ecc

Yes indeed.

Regards,    Martin. 

From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue Jan  3 16:22:54 2006
Subject: MIME Type Review for KPML MIME Types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

* Eric Burger wrote:
>KPML is in the process of WGLC in the SIPPING work group.
>
>KPML defines two new MIME types, application/kpml-request+xml and
>application/kpml-response+xml .
>
>We would greatly appreciate expert review of the definition and usage of
>these new types.
>
>The draft lives at:
>http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt

Did the Working Group consider using the message/* top-level type?
-- 
Bj?rn H?hrmann ? mailto:[email-masked] ? http://bjoern.hoehrmann.de
Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de
68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:54 2006
Subject: Registration of MIME media type .pss
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

(same comments on the application/.ecc registration)

On Thursday, December 9, 2004, 10:07:45 PM, Tony wrote:
  
TM> To: [email-masked]
TM> ???? Subject: Registration of MIME media type *.pss
TM> ?
TM> ???? MIME media type name: Application??????? 
TM> ?
TM> ???? MIME subtype name: .pss

Why the leading dot? Note that the dot has a syntactic use in media type
names.
  
TM> ???? Security considerations: none

This is unlikely. Some indication should be given of why this data is
harmless. This is particularly the case in the absence of a published
specification.

TM> ?
TM> ???? Interoperability considerations: none
TM> ?
TM> ???? Published specification: The specifications for this
TM> content type are proprietary. They are specified by Essential
TM> Security Software, Inc.

In that case, would a vendor tree registration not be more appropriate?

application/vnd.ess.pss
(note - not application/vnd..ess.pss )

and similarly

application/vnd.ess.ecc

TM> ??? ?Applications which use this media type: Essential Security
TM> Software product, Essential Security Suite and Ecrypt-it. Contains
TM> encrypted information.
TM> ?
TM> ???? Additional information:
TM> ?
TM> ?????? Magic number(s): none?? 
TM> ?????? File extension(s): *.pss
TM> ?????? Macintosh File Type Code(s): none
TM> ?
TM> ???? Person & email address to contact for further information:
TM> ?
TM> ??????? Tony Mohr
TM> ??????? [email-masked]
TM> ??????? 425.454.2632
TM> ?
TM> ???? Intended usage: common
TM> ?
TM> ???? (One of COMMON, LIMITED USE or OBSOLETE)

Why common? It sounds as if limited would be more likely, if its for
internal use in two products.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: eburger at brooktrout.com (Eric Burger)
Date: Tue Jan  3 16:22:53 2006
Subject: MIME Type Review Request: application/kpml-request+xml and applic ation/kpml-response+xml
Message-ID: <[email-masked]>

Please review the MIME type registration template described below.  

This registration is part of the KPML specification, a work group item in
the SIPPING work group.  The SIPPING work group has completed Work Group
Last Call on KPML.

The Internet Draft is at:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

kpml-request+xml
================
   MIME media type name: application

   MIME subtype name: kpml-request+xml

   Required parameters: none

   Optional parameters: Same as charset parameter application/xml as
      specified in XML Media Types [3]

   Encoding considerations: See RFC3023 [3].

   Security considerations: See Section 10 of RFC3023 [3] and Section 8
      of http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Interoperability considerations: See RFC2023 [3] and
      http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Published specification:
      http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Applications which use this media type: Session-oriented applications
      that have primitive User Interfaces.

   Change controller: SIPPING Working Group delegated from the IESG

   Personal and email address for further information: Eric Burger
      <[email-masked]>

   Intended usage: COMMON

kpml-response+xml
=================
   MIME media type name: application

   MIME subtype name: kpml-resposne+xml

   Required parameters: none

   Optional parameters: Same as charset parameter application/xml as
      specified in XML Media Types [3]

   Encoding considerations: See RFC3023 [3].

   Security considerations: See Section 10 of RFC3023 [3] and Section 8
      of http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Interoperability considerations: See RFC2023 [3] and
      http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Published specification:
      http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Applications which use this media type: Session-oriented applications
      that have primitive User Interfaces.

   Change controller: SIPPING Working Group delegated from the IESG

   Personal and email address for further information: Eric Burger
      <[email-masked]>

   Intended usage: COMMON

From: blilly at erols.com (Bruce Lilly)
Date: Tue Jan  3 16:22:53 2006
Subject: I-D ACTION:draft-lilly-text-troff-00.txt; registration vs. other specifications
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

There have been a number of comments specifically related to
security matters.  As mentioned, I believe security issues are
covered in the draft text in the Security Considerations of
the registration template which comprises a significant part
of the draft, and the separate Security Considerations section
of the draft per se, which refers back to the section in the
registration template.

One of the considerations that went into the writing of the draft
is the distinction between registration of the media subtype vs.
other specifications.  One issue is that with security matters
one would like to use BCP14 (a.k.a. RFC 2119) keywords, but that
hardly seems appropriate for mere registration.  And the sole
purpose of the draft is to register the media subtype.  There
are a few instances of RFC 2119 language in the registration
template in the draft, and that makes me slightly uneasy. Short
of some authoritative indication that BCP14 language is appropriate
in a registration template, I would not be inclined to further
increase use of those keywords.

If those who have commented on security-related matters still
feel that the discussion in the draft is inadequate, I could
repeat the material outside of the registration template and use
suitable RFC 2119 keywords there.  However, that leaves the
issue of the eventual status of the document, as well as the
issue of lack of enforcement mechanisms.  The draft is an
individual submission; as I understand the procedures, there
are two paths for it to publication as an RFC:
1. as an individual submission via the RFC Editor, in which
   case there is likely to be an IESG note disclaiming any
   knowledge of fitness for any purpose (RFC 3932).
2. by a request to the IETF for review and publication as
   an RFC.  Publication by this route would certainly require
   some AD action. Most likely the category would be Informational,
   which is off the standards track, i.e. "does not specify
   an Internet standard of any kind".  I believe that
   category would suffice for the purpose of registering the
   media type, and that is the category that I would request.
In either case, it's slightly unclear what practical effect, if
any, presence of RFC 2119 language would have.  RFC 2119's
Abstract specifically mentions standards track documents, but
also mentions more generic "IETF documents"; it also notes
"that the force of these words is modified by the requirement
level of the document in which they are used".  My understanding
is that "requirement level" is something that would be specified
in an Applicability Statement, which would be a separate document
from the Technical Specification of the media subtype.

My reading of the proposed revision to the media type registration
procedure (draft-freed-media-type-reg-01) is that route #1 above
would be prohibited for registration in the Standards Tree (i.e.
under text) as it is not approved by the IESG ("Registrations in
the standards tree MUST be approved by the IESG [...]").  There
is a similar passage in RFC 2048, but the tree itself is therein
referred to as the "IETF Tree".

In light of all of the above, I would like to ask if those who
have raised issues are satisfied with the draft text, and if not
what specifically do they propose as a solution consistent with
the considerations above and as previously discussed.

Some clarification of the intent of the registration procedures
documents w.r.t. RFC Editor vs. IETF paths, and of suitability of
BCP14 language within the registration template might also be
helpful, as would comments from the Applications Area ADs regarding
applicable procedures and policies.

From: eburger at brooktrout.com (Eric Burger)
Date: Fri Jan  7 03:40:10 2005
Subject: Error in Access-Types Tables
Message-ID: <[email-masked]>

-----Original Message-----
From: Eric Burger 
Sent: Thursday, January 06, 2005 9:16 PM
To: [email-masked]; [email-masked]
Cc: Ted Hardie (E-mail); Scott Hollenbeck (E-mail)
Subject: Error in Access-Types Tables

The page http://www.iana.org/assignments/media-types-parameters has a table
of "Access Types".  That table is out of date and inaccurate.

The page http://www.iana.org/assignments/access-types has a mostly correct
list.  The references to RFC2048 actually should be to RFC2046.

I would propose removing the table on the media-types-parameters page and
putting an explicit link to the access-types page.

Thanks. 
>From [email-masked]  Sun Jan  9 19:22:34 2005
From: blilly at erols.com (Bruce Lilly)
Date: Sun Jan  9 20:51:43 2005
Subject: I-D ACTION:draft-lilly-text-troff-00.txt;
	registration vs. other specifications
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

There have been a number of comments specifically related to
security matters.  As mentioned, I believe security issues are
covered in the draft text in the Security Considerations of
the registration template which comprises a significant part
of the draft, and the separate Security Considerations section
of the draft per se, which refers back to the section in the
registration template.

One of the considerations that went into the writing of the draft
is the distinction between registration of the media subtype vs.
other specifications.  One issue is that with security matters
one would like to use BCP14 (a.k.a. RFC 2119) keywords, but that
hardly seems appropriate for mere registration.  And the sole
purpose of the draft is to register the media subtype.  There
are a few instances of RFC 2119 language in the registration
template in the draft, and that makes me slightly uneasy. Short
of some authoritative indication that BCP14 language is appropriate
in a registration template, I would not be inclined to further
increase use of those keywords.

If those who have commented on security-related matters still
feel that the discussion in the draft is inadequate, I could
repeat the material outside of the registration template and use
suitable RFC 2119 keywords there.  However, that leaves the
issue of the eventual status of the document, as well as the
issue of lack of enforcement mechanisms.  The draft is an
individual submission; as I understand the procedures, there
are two paths for it to publication as an RFC:
1. as an individual submission via the RFC Editor, in which
   case there is likely to be an IESG note disclaiming any
   knowledge of fitness for any purpose (RFC 3932).
2. by a request to the IETF for review and publication as
   an RFC.  Publication by this route would certainly require
   some AD action. Most likely the category would be Informational,
   which is off the standards track, i.e. "does not specify
   an Internet standard of any kind".  I believe that
   category would suffice for the purpose of registering the
   media type, and that is the category that I would request.
In either case, it's slightly unclear what practical effect, if
any, presence of RFC 2119 language would have.  RFC 2119's
Abstract specifically mentions standards track documents, but
also mentions more generic "IETF documents"; it also notes
"that the force of these words is modified by the requirement
level of the document in which they are used".  My understanding
is that "requirement level" is something that would be specified
in an Applicability Statement, which would be a separate document
from the Technical Specification of the media subtype.

My reading of the proposed revision to the media type registration
procedure (draft-freed-media-type-reg-01) is that route #1 above
would be prohibited for registration in the Standards Tree (i.e.
under text) as it is not approved by the IESG ("Registrations in
the standards tree MUST be approved by the IESG [...]").  There
is a similar passage in RFC 2048, but the tree itself is therein
referred to as the "IETF Tree".

In light of all of the above, I would like to ask if those who
have raised issues are satisfied with the draft text, and if not
what specifically do they propose as a solution consistent with
the considerations above and as previously discussed.

Some clarification of the intent of the registration procedures
documents w.r.t. RFC Editor vs. IETF paths, and of suitability of
BCP14 language within the registration template might also be
helpful, as would comments from the Applications Area ADs regarding
applicable procedures and policies.
>From [email-masked]  Tue Jan 11 21:14:35 2005
From: eburger at brooktrout.com (Eric Burger)
Date: Tue Jan 11 21:24:38 2005
Subject: MIME Type Review Request: application/kpml-request+xml and applic
	ation/kpml-response+xml
Message-ID: <[email-masked]>

Please review the MIME type registration template described below.  

This registration is part of the KPML specification, a work group item in
the SIPPING work group.  The SIPPING work group has completed Work Group
Last Call on KPML.

The Internet Draft is at:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

kpml-request+xml
================
   MIME media type name: application

   MIME subtype name: kpml-request+xml

   Required parameters: none

   Optional parameters: Same as charset parameter application/xml as
      specified in XML Media Types [3]

   Encoding considerations: See RFC3023 [3].

   Security considerations: See Section 10 of RFC3023 [3] and Section 8
      of http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Interoperability considerations: See RFC2023 [3] and
      http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Published specification:
      http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Applications which use this media type: Session-oriented applications
      that have primitive User Interfaces.

   Change controller: SIPPING Working Group delegated from the IESG

   Personal and email address for further information: Eric Burger
      <[email-masked]>

   Intended usage: COMMON

kpml-response+xml
=================
   MIME media type name: application

   MIME subtype name: kpml-resposne+xml

   Required parameters: none

   Optional parameters: Same as charset parameter application/xml as
      specified in XML Media Types [3]

   Encoding considerations: See RFC3023 [3].

   Security considerations: See Section 10 of RFC3023 [3] and Section 8
      of http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Interoperability considerations: See RFC2023 [3] and
      http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Published specification:
      http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt

   Applications which use this media type: Session-oriented applications
      that have primitive User Interfaces.

   Change controller: SIPPING Working Group delegated from the IESG

   Personal and email address for further information: Eric Burger
      <[email-masked]>

   Intended usage: COMMON
>From [email-masked]  Tue Jan  4 17:51:24 2005
From: mhammer at cisco.com (Mike Hammer)
Date: Thu Jan 20 19:33:12 2005
Subject: Registration of media type "application/nss"
In-Reply-To: <20041231005848.ZRJR16610.lakermmtao08.cox.net@A31P>
Message-ID: <[email-masked]>

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:[email-masked]] 
Sent: Thursday, December 30, 2004 7:59 PM
To: 'Mike Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
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:[email-masked]]
> Sent: Thursday, December 30, 2004 1:52 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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: [email-masked]
> 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:  [email-masked]
>    Author/Change controller:  ITU-T Study Group 11
> 
> END
> 
> 
>From [email-masked]  Thu Jan 20 22:45:14 2005
From: chris at w3.org (Chris Lilley)
Date: Thu Jan 20 22:45:21 2005
Subject: Registration of MIME media type .pss
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

(same comments on the application/.ecc registration)

On Thursday, December 9, 2004, 10:07:45 PM, Tony wrote:
  
TM> To: [email-masked]
TM> ???? Subject: Registration of MIME media type *.pss
TM> ?
TM> ???? MIME media type name: Application??????? 
TM> ?
TM> ???? MIME subtype name: .pss

Why the leading dot? Note that the dot has a syntactic use in media type
names.
  
TM> ???? Security considerations: none

This is unlikely. Some indication should be given of why this data is
harmless. This is particularly the case in the absence of a published
specification.

TM> ?
TM> ???? Interoperability considerations: none
TM> ?
TM> ???? Published specification: The specifications for this
TM> content type are proprietary. They are specified by Essential
TM> Security Software, Inc.

In that case, would a vendor tree registration not be more appropriate?

application/vnd.ess.pss
(note - not application/vnd..ess.pss )

and similarly

application/vnd.ess.ecc

TM> ??? ?Applications which use this media type: Essential Security
TM> Software product, Essential Security Suite and Ecrypt-it. Contains
TM> encrypted information.
TM> ?
TM> ???? Additional information:
TM> ?
TM> ?????? Magic number(s): none?? 
TM> ?????? File extension(s): *.pss
TM> ?????? Macintosh File Type Code(s): none
TM> ?
TM> ???? Person & email address to contact for further information:
TM> ?
TM> ??????? Tony Mohr
TM> ??????? [email-masked]
TM> ??????? 425.454.2632
TM> ?
TM> ???? Intended usage: common
TM> ?
TM> ???? (One of COMMON, LIMITED USE or OBSOLETE)

Why common? It sounds as if limited would be more likely, if its for
internal use in two products.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: eburger at brooktrout.com (Eric Burger)
Date: Tue Jan  3 16:22:53 2006
Subject: Error in Access-Types Tables
Message-ID: <[email-masked]>

-----Original Message-----
From: Eric Burger 
Sent: Thursday, January 06, 2005 9:16 PM
To: [email-masked]; [email-masked]
Cc: Ted Hardie (E-mail); Scott Hollenbeck (E-mail)
Subject: Error in Access-Types Tables

The page http://www.iana.org/assignments/media-types-parameters has a table
of "Access Types".  That table is out of date and inaccurate.

The page http://www.iana.org/assignments/access-types has a mostly correct
list.  The references to RFC2048 actually should be to RFC2046.

I would propose removing the table on the media-types-parameters page and
putting an explicit link to the access-types page.

Thanks. 

From: sah at 428cobrajet.net (Scott Hollenbeck)
Date: Wed Jan  5 00:09:18 2005
Subject: Registration of media type "application/nss"
In-Reply-To: <20041231005848.ZRJR16610.lakermmtao08.cox.net@A31P>
Message-ID: <20050104230905.LIRU16431.lakermmtao05.cox.net@A31P>

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:[email-masked]] 
> Sent: Thursday, December 30, 2004 7:59 PM
> To: 'Mike Hammer'; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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:[email-masked]]
> > Sent: Thursday, December 30, 2004 1:52 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > 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: [email-masked]
> > 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:  [email-masked]
> >    Author/Change controller:  ITU-T Study Group 11
> > 
> > END
> > 
> > 
> 
> 

From: mhammer at cisco.com (Mike Hammer)
Date: Tue Jan  3 16:22:54 2006
Subject: Registration of media type "application/nss"
In-Reply-To: <20041231005848.ZRJR16610.lakermmtao08.cox.net@A31P>
Message-ID: <[email-masked]>

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:[email-masked]] 
Sent: Thursday, December 30, 2004 7:59 PM
To: 'Mike Hammer'; [email-masked]
Cc: [email-masked]; [email-masked]
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:[email-masked]]
> Sent: Thursday, December 30, 2004 1:52 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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: [email-masked]
> 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:  [email-masked]
>    Author/Change controller:  ITU-T Study Group 11
> 
> END
> 
>