Re: [apps-discuss] [Ecrit] review of draft-ietf-ecrit-lost-sync-12

Robert Sparks <> Mon, 05 March 2012 22:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83EB021F87D3; Mon, 5 Mar 2012 14:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.39
X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S7tmro8avpjg; Mon, 5 Mar 2012 14:15:01 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 5B17721F844F; Mon, 5 Mar 2012 14:14:59 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q25MEppd054150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 16:14:52 -0600 (CST) (envelope-from
Message-ID: <>
Date: Mon, 05 Mar 2012 16:15:01 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc:,, "" <>
Subject: Re: [apps-discuss] [Ecrit] review of draft-ietf-ecrit-lost-sync-12
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Mar 2012 22:15:02 -0000

(One typo correction inline)

On 3/5/12 4:05 PM, Robert Sparks wrote:
> There's an aspect of this document that I want to make sure folks 
> aren't missing.
> The things lostsync1 are adding are not things that something that 
> speaks lost will every say.

> It's not an iteration of the lost vocabulary in that sense.
> It is something spoken by things that talk about lost speakers.
> This is not an extension of Lost. It is a different protocol that 
> replicates the data used to
> answer Lost queries. It reuses the format that Lost uses when talking 
> about that data.
> Does that make a difference in whether a new namespace is appropriate?
> (No is an OK answer - I don't have a strong opinion, but my instinct 
> says that the separate
> namespace is likely to introduce fewer problems because of a bad 
> assumption an implementer
> could make if the values were in the same namespace).
> RjS
> On 2/23/12 4:38 AM, "Martin J. Dürst" wrote:
>> Hello Peter, others,
>> On 2012/02/23 6:55, Peter Saint-Andre wrote:
>>> Robert Sparks asked me to think about the namespaces issue...
>>>> -------- Original Message -------- Subject:     Re: review of
>>>> draft-ietf-ecrit-lost-sync-12 Date:     Fri, 13 Jan 2012 11:17:10 
>>>> +0200
>>>> From:     Hannes Tschofenig<>  To:     
>>>> "Martin J.
>>>> Dürst"<>  CC:     Hannes Tschofenig
>>>> <>, Henning Schulzrinne
>>>> <>, Marc Linsner<>,
>>>> Robert Sparks<>, ""
>>>> <>,
>>>>>  From Martin:
>>>>> Namespaces: It is overkill to define new namespaces for each spec.
>>>>> It's a well-known secret in the XML community that it's easily
>>>>> possible to add a number of new elements to an existing namespace.
>>>>> This would be very appropriate in this case, because the number of
>>>>> reused elements and attributes is quite large, and the number of
>>>>> new elements is low. This would simplify most of the examples.
>>>> I guess you refer to the namespace registration in the IANA
>>>> consideration section, namely urn:ietf:params:xml:ns:lostsync1
>>>> In the RAI area we have (to my knowledge) always created new
>>>> namespaces for new schemas. But I am pleased to hear that this is not
>>>> needed.
>>>> Could you explain what we should be doing instead?
>> Rather than define a new namespace lostsync1, just add the few 
>> elements you defined anew to the lost1 namespace. It will make the 
>> format simpler, and it won't hurt.
>>> I don't see a problem with defining a new namespace for each iteration
>>> of an XML format (lostsync1, lostsync2, etc.),
>> There's no 'problem' with defining a separate namespace for each 
>> element. Correct software should still work. But it's not really 
>> necessary, it's tedious for human users and just overkill.
>>> because I don't think
>>> there's a general case here -- backward compatibility can depend on the
>>> community of interest. One community might be doing strict schema
>>> checking, so that any new elements or attributes would be problematic.
>>> By contrast, another community might be more lax in its processing
>>> because they specify that applications must ignore unknown elements and
>>> attributes, even those qualified by an existing namespace.
>> Validation is largely independent of namespaces. There are some 
>> problems with validating documents with more than one namespace, 
>> depending on the technology (I'd have to look up the details), but 
>> there are NO issues, with any of the validating technologies around 
>> (DTDs, XML Schema, Relaxing, Schematron), when having only one 
>> namespace and validating against subsets thereof.
>> W3C technologies regularly do that (XHTML and SVG are the examples I 
>> know best). Way, way back there was a heated discussion in the XML 
>> community about whether a new namespace would make sense for a new 
>> version of XHTML, and this was strongly and utterly rejected. The way 
>> it was put most prominently was "a <p> is a <p> is a <p>".
>> Validation is not only different for versions, but as you have 
>> explained also for various other purposes. Some applications may use 
>> validation to introduce further restrictions (e.g. for security 
>> reasons in certain places), and so on.
>> A new namespace for a new version only make sense if the old and the 
>> new version are something completely different, with essentially no 
>> common elements and no documents that would be acceptable in both 
>> versions. For other cases, using separate namespaces just increases 
>> clutter without contributing anything.
>> The same is the case here. The proposed "lostsync1" namespace doesn't 
>> contain many elements, and is only useful together with the "lost1" 
>> namespace. That's of course unless the people in charge of the LOST 
>> protocol and the people who came up with LOSTSYNC totally distrust 
>> each other, but I was just assuming that's not the case :-).
>> Regards,    Martin.
> _______________________________________________
> Ecrit mailing list